[Freeipa-users] Re: Replication and SSL certs
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
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
On Mon, Jul 17, 2017 at 08:48:36AM -0400, Mark Haney wrote: > On 07/16/2017 09:47 PM, Fraser Tweedale wrote: > > > > 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 > > That's good info to have, but I keep hearing that wildcard certs are > deprecated/going away, but I've seen nothing from any sources (outside of > mailing lists) that back that up. I'm curious as to why that is (I know why > wildcards are considered bad), but why I've not seen anything remotely > official on it. > 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! 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
On 07/16/2017 09:47 PM, Fraser Tweedale wrote: 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 That's good info to have, but I keep hearing that wildcard certs are deprecated/going away, but I've seen nothing from any sources (outside of mailing lists) that back that up. I'm curious as to why that is (I know why wildcards are considered bad), but why I've not seen anything remotely official on it. -- 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
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
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
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
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
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
