[Freeipa-users] Re: Replication and SSL certs

2017-07-17 Thread Fraser Tweedale via FreeIPA-users
On Mon, Jul 17, 2017 at 10:18:40AM -0400, Mark Haney wrote:
> On 07/17/2017 09:27 AM, Fraser Tweedale wrote:
> > 
> > https://tools.ietf.org/html/rfc6125#section-7.2
> > 
> >  This document states that the wildcard character '*' SHOULD NOT
> >  be included in presented identifiers but MAY be checked by
> >  application clients (mainly for the sake of backward
> >  compatibility with deployed infrastructure).
> > 
> > Furthermore, note that wildcards in dNSName values (SAN), although
> > supported by most clients, are technically a violation of RFC 5280.
> > The deprecation (and now, actual removal in clients) of CN-based
> > validation poses another challenge in this regard.
> > 
> > Some years ago it seemed impossible that CN-based hostname
> > validation, despite being officialy deprecated in RFC 2818 and the
> > deprecation affirmed by RFC 6125, would ever happen.  But it has
> > happened.  The thing is... "all the clients still support it"...
> > until they don't anymore!
> Okay, I'm aware of the reasoning, and the implications of having wildcards
> in the SAN, but I'm still not seeing like a drop/removal deadline date for
> this. We handle several hundred certs for our clients, some of which are
> wildcards, and it would be nice to know when this will become a serious
> issue long before it bites us in the butt.
> 
> (Yeah, I know it's a ginormously stupid question, but I typically don't muck
> with wildcard certs, so this isn't something I have had to deal with.)
> 
Noone knows "when".  Just like noone knew "when" re the CN
deprecation, until Google went ahead and did it with not much notice
(2 or 3 months).

But the context is: the public PKI had to put all naming info in
SANs for quite a while.  At the time Google became first mover to
disable CN validation, there was nil chance of any impact on the
public PKI.  This is certainly not the case for wildcards today, but
efforts like Let's Encrypt are likely reducing the incidence of
wildcard certs in the wild.  (OTOH, LE just announced wildcard cert
support, albeit with a somewhat restricted scope, so go figure).

Even though there seems to be no hurry, my advice is to encourage
and assist customers to begin moving away from wildcard certs, where
it is practical to do so.

Cheers,
Fraser

> 
> -- 
> Mark Haney
> Network Engineer at NeoNova
> 919-460-3330 option 1
> mark.ha...@neonova.net
> www.neonova.net
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-17 Thread Mark Haney via FreeIPA-users

On 07/17/2017 09:27 AM, Fraser Tweedale wrote:


https://tools.ietf.org/html/rfc6125#section-7.2

 This document states that the wildcard character '*' SHOULD NOT
 be included in presented identifiers but MAY be checked by
 application clients (mainly for the sake of backward
 compatibility with deployed infrastructure).

Furthermore, note that wildcards in dNSName values (SAN), although
supported by most clients, are technically a violation of RFC 5280.
The deprecation (and now, actual removal in clients) of CN-based
validation poses another challenge in this regard.

Some years ago it seemed impossible that CN-based hostname
validation, despite being officialy deprecated in RFC 2818 and the
deprecation affirmed by RFC 6125, would ever happen.  But it has
happened.  The thing is... "all the clients still support it"...
until they don't anymore!
Okay, I'm aware of the reasoning, and the implications of having 
wildcards in the SAN, but I'm still not seeing like a drop/removal 
deadline date for this. We handle several hundred certs for our clients, 
some of which are wildcards, and it would be nice to know when this will 
become a serious issue long before it bites us in the butt.


(Yeah, I know it's a ginormously stupid question, but I typically don't 
muck with wildcard certs, so this isn't something I have had to deal with.)



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-16 Thread Fraser Tweedale via FreeIPA-users
On Fri, Jul 14, 2017 at 07:47:39AM -0400, Mark Haney via FreeIPA-users wrote:
> On 07/13/2017 09:57 PM, Fraser Tweedale wrote:
> > OK, I think I understand.
> > 
> > ipa0 has been set up with a 3rd-party HTTP cert, but ipa1 has been
> > set up with a certificate issued by the IPA CA, which your browser
> > does not trust.
> > 
> > There are two ways forward here:
> > 
> > 1.  You can use ipa-server-certinstall to install a 3rd-party (i.e.
> > not issued by the IPA CA but by a CA trusted by clients - including
> > browsers - in your organisation) certificate for the HTTP service.
> > This seems to be how ipa0 is set up so you might want to do that for
> > consistency.
> > 
> > 2.  Add the IPA CA certificate to your browser as a trusted CA.  If
> > you need all clients (including users' browsers) in your
> > organisation to trust certs issued by your FreeIPA CA, then you need
> > to work out how to push the IPA CA out to all of them, or you need
> > to chain the IPA CA to a CA that they already trust (e.g.
> > organisations with Active Directory often chain their IPA CA up to
> > the AD CA).
> 
> Yeah, I got it figured out.  For some reason, I expected /all/ the SSL certs
> to be carried over when I went through the steps to build the replica
> server.  All of the /internal/ IPA ones did just fine. It seems that the
> wildcard cert that we're using for securing the Web interface did not (and
> probably doesn't for anyone else).  We have a GoDaddy signed wildcard SSL
> cert we use for any web interface (we're HTTPS-only now).  The process to
> setup the IPA replica didn't include that cert when I ran
> 'ipa-replica-install ipa0.gpg'.  So, I had to copy the CA bundle, .crt &.key
> files and manually install them using ipa-cacert-manage and
> ipa-server-certinstall.
> 
> I sort of expected the replica to be an identical replica in all settings,
> but maybe that was too high an expectation.  Regardless, I have it
> configured and working properly, so I can move onto putting it into
> production.
> 
Glad you've figured it out.

In general, there must be different certs on a replica because the
hostname is different.  IPA does not do the work to figure out that
the wildcard cert on the master will be valid for the replica too
and therefore use it for the replica services - and it almost
certainly never will (wildcard certs are deprecated).

But, during ipa-replica-intsall(1) you can provide certificates for
the Directory Server and Apache HTTPD via the --dirsrv-cert-file and
--http-cert-file options.  This way you can give the replica the
wildcard certs from the start, and it will not issue certs from the
IPA CA for these services.  This would have achieved the desired
outcome.

Cheers,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-14 Thread Mark Haney via FreeIPA-users

On 07/13/2017 09:57 PM, Fraser Tweedale wrote:

OK, I think I understand.

ipa0 has been set up with a 3rd-party HTTP cert, but ipa1 has been
set up with a certificate issued by the IPA CA, which your browser
does not trust.

There are two ways forward here:

1.  You can use ipa-server-certinstall to install a 3rd-party (i.e.
not issued by the IPA CA but by a CA trusted by clients - including
browsers - in your organisation) certificate for the HTTP service.
This seems to be how ipa0 is set up so you might want to do that for
consistency.

2.  Add the IPA CA certificate to your browser as a trusted CA.  If
you need all clients (including users' browsers) in your
organisation to trust certs issued by your FreeIPA CA, then you need
to work out how to push the IPA CA out to all of them, or you need
to chain the IPA CA to a CA that they already trust (e.g.
organisations with Active Directory often chain their IPA CA up to
the AD CA).


Yeah, I got it figured out.  For some reason, I expected /all/ the SSL 
certs to be carried over when I went through the steps to build the 
replica server.  All of the /internal/ IPA ones did just fine. It seems 
that the wildcard cert that we're using for securing the Web interface 
did not (and probably doesn't for anyone else).  We have a GoDaddy 
signed wildcard SSL cert we use for any web interface (we're HTTPS-only 
now).  The process to setup the IPA replica didn't include that cert 
when I ran 'ipa-replica-install ipa0.gpg'.  So, I had to copy the CA 
bundle, .crt &.key files and manually install them using 
ipa-cacert-manage and ipa-server-certinstall.


I sort of expected the replica to be an identical replica in all 
settings, but maybe that was too high an expectation.  Regardless, I 
have it configured and working properly, so I can move onto putting it 
into production.


--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-13 Thread Fraser Tweedale via FreeIPA-users
On Thu, Jul 13, 2017 at 09:57:04AM -0400, Mark Haney via FreeIPA-users wrote:
> On 07/12/2017 08:34 PM, Fraser Tweedale wrote:
> > 
> > Which version(s) of FreeIPA?
> ipa-server-4.4.0-14.el7.centos.7.x86_64
> > 
> > Which service(s) (HTTP, LDAP?).
> HTTPS.  I haven't checked LDAPS yet.  It appears this is only related to
> HTTPS.  To give a bit of backstory, the primary host [ipa0] was installed
> and configured a couple of months before I came on board here (which was in
> early April). One of my first tasks was to build a replica of ipa0 (wackily
> named ipa1) for redundancy.
> > 
> > What client program(s) were used to contact the servers?  (The same
> > client, or different?)  Has the IPA CA cert been properly installed
> > for the relevant clients / client systems?
> I've not even tried to connect clients yet, this is solely related to the
> web browser complaining about the connection to the admin panel being
> insecure on ipa1, but not ipa0.  ipa0 has a valid not self-signed wildcard
> cert on it.  SO, either the process I used to build the replica and get it
> synced was incorrect, or the process doesn't include valid non-self-signed
> HTTPS certs.  That's where I'm at now.
>
OK, I think I understand.

ipa0 has been set up with a 3rd-party HTTP cert, but ipa1 has been
set up with a certificate issued by the IPA CA, which your browser
does not trust.

There are two ways forward here:

1.  You can use ipa-server-certinstall to install a 3rd-party (i.e.
not issued by the IPA CA but by a CA trusted by clients - including
browsers - in your organisation) certificate for the HTTP service.
This seems to be how ipa0 is set up so you might want to do that for
consistency.

2.  Add the IPA CA certificate to your browser as a trusted CA.  If
you need all clients (including users' browsers) in your
organisation to trust certs issued by your FreeIPA CA, then you need
to work out how to push the IPA CA out to all of them, or you need
to chain the IPA CA to a CA that they already trust (e.g.
organisations with Active Directory often chain their IPA CA up to
the AD CA).

HTH,
Fraser

> > 
> > Can you show us the good / bad certs?
> > 
> > {{There are a lot of things to check when diagnosing PKI problems!}}
> > 
> > Thanks,
> > Fraser
> 
> 
> -- 
> Mark Haney
> Network Engineer at NeoNova
> 919-460-3330 option 1
> mark.ha...@neonova.net
> www.neonova.net
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-13 Thread Mark Haney via FreeIPA-users

On 07/12/2017 08:34 PM, Fraser Tweedale wrote:


Which version(s) of FreeIPA?

ipa-server-4.4.0-14.el7.centos.7.x86_64


Which service(s) (HTTP, LDAP?).
HTTPS.  I haven't checked LDAPS yet.  It appears this is only related to 
HTTPS.  To give a bit of backstory, the primary host [ipa0] was 
installed and configured a couple of months before I came on board here 
(which was in early April). One of my first tasks was to build a replica 
of ipa0 (wackily named ipa1) for redundancy.


What client program(s) were used to contact the servers?  (The same
client, or different?)  Has the IPA CA cert been properly installed
for the relevant clients / client systems?
I've not even tried to connect clients yet, this is solely related to 
the web browser complaining about the connection to the admin panel 
being insecure on ipa1, but not ipa0.  ipa0 has a valid not self-signed 
wildcard cert on it.  SO, either the process I used to build the replica 
and get it synced was incorrect, or the process doesn't include valid 
non-self-signed HTTPS certs.  That's where I'm at now.


Can you show us the good / bad certs?

{{There are a lot of things to check when diagnosing PKI problems!}}

Thanks,
Fraser



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Replication and SSL certs

2017-07-12 Thread Fraser Tweedale via FreeIPA-users
On Wed, Jul 12, 2017 at 01:20:36PM -0400, Mark Haney via FreeIPA-users wrote:
> I'm really new to FreeIPA, and this is probably a stupid question, but I
> just setup a replica of the primary (not in production) IPA server we have.
> However, the replica's SSL cert is untrusted, while the primary IPA server's
> cert is fine.  The docs I read said the SSL certs would be carried over when
> building the replica GPG file and installing the replica data.
> 
> Have I missed something in the replication setup process?
> 
Which version(s) of FreeIPA?

Which service(s) (HTTP, LDAP?).

What client program(s) were used to contact the servers?  (The same
client, or different?)  Has the IPA CA cert been properly installed
for the relevant clients / client systems?

Can you show us the good / bad certs?

{{There are a lot of things to check when diagnosing PKI problems!}}

Thanks,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org