Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates
On Wed, Apr 05, 2017 at 10:38:48PM -0700, Wim Lewis wrote: > With a bit of tweaking, I was able to generate a usable > certificate by creating a second host entry, > 'wildcard.blah.example.com', managed by blah.example.com, and then > editing the leftmost label from 'wildcard' to '*' in all of the > host's LDAP entry's properties. > Suffice to say: this is not a supported or recommended approach :) > > On Apr 3, 2017, at 6:41 PM, Fraser Tweedale wrote: > > The only way is to create a profile that hard-codes the desired SAN > > data, then use that profile. > > Out of curiosity, if my LDAP approach didn't work, how would I do > that? I assume it involves `ipa certprofile-import`, but is there > any documentation on the format it expects? The examples I've > found have no mention of SANs at all, so it's not clear how I > would hard code the desired SAN. > Have a look at: https://www.redhat.com/archives/pki-users/2014-January/msg5.html Based on the example there you would change a couple of config. policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName policyset.serverCertSet.9.default.params.subjAltExtPattern_0=*.blah.exmaple.com The rest of the profile config could be a direct copy of caIPAserviceCert, although it would be sensible to remote the 'userExtDefault' component, which is used to copy a SAN extension from the CSR, would could cause a conflict. > > Is your instance publicly hosted? Perhaps the sandstorm.io > > developers could support ACME/Let's Encrypt so that certs can be > > automatically acquired for each domain... > > This would be possible, I assume, but it would couple the > sandstorm instance rather tightly to its CA --- requiring the CA > to issue a certificate for every new user session. Let's Encrypt > does rate limiting which would prevent this, for example. > Right. Let's Encrypt does rate limit per registered domain (max 20 per week according to [1]). So that would seem to be too low for your use case. [1] https://letsencrypt.org/docs/rate-limits/ > An alternative would be to run a local sub-CA for uses like > sandstorm, but this would require a CA to support issuing > name-constrained sub-CAs (and if wildcard certs are considered too > sloppily implemented in real-world clients to be trustworthy, then > name constraints definitely are!). > If you trust the IPA CA, you could create a sub-CA under it, export it, and use it with whatever software can meet your needs. But this leads me to the question: are you using FreeIPA already and trying to work out how to fit the Sandstorm use case into it? Or are you just looking for a solution for Sandstorm? > > But see also §7.2 which states that wildcard certs are > > deprecated :) https://tools.ietf.org/html/rfc6125#section-7.2 > > Only mostly deprecated; it admits of legitimate uses for them. :) > Wildcards are not the best feature of the web PKI, I agree, and I > wouldn't want to use them if I could think of a viable > alternative. > The fact that you are looking at FreeIPA suggests that you will be anchoring your trust at some private CA (not a publicly trusted CA). If that is the case, then you always have the viable option, "build the software you need". It may not exist OOTB but AFAICS there is nothing fundamentally difficult about your use case. > (And consider that putting domains in the CN has been deprecated > since HTTPS/TLS was even a standard, back in 2000 --- yet everyone > still does that.) > Sure, but do not hold it against us if we follow the standards :) Thanks, Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates
With a bit of tweaking, I was able to generate a usable certificate by creating a second host entry, 'wildcard.blah.example.com', managed by blah.example.com, and then editing the leftmost label from 'wildcard' to '*' in all of the host's LDAP entry's properties. On Apr 3, 2017, at 6:41 PM, Fraser Tweedale wrote: > The only way is to create a profile that hard-codes the desired SAN > data, then use that profile. Out of curiosity, if my LDAP approach didn't work, how would I do that? I assume it involves `ipa certprofile-import`, but is there any documentation on the format it expects? The examples I've found have no mention of SANs at all, so it's not clear how I would hard code the desired SAN. > Is your instance publicly hosted? Perhaps the sandstorm.io > developers could support ACME/Let's Encrypt so that certs can be > automatically acquired for each domain... This would be possible, I assume, but it would couple the sandstorm instance rather tightly to its CA --- requiring the CA to issue a certificate for every new user session. Let's Encrypt does rate limiting which would prevent this, for example. An alternative would be to run a local sub-CA for uses like sandstorm, but this would require a CA to support issuing name-constrained sub-CAs (and if wildcard certs are considered too sloppily implemented in real-world clients to be trustworthy, then name constraints definitely are!). > But see also §7.2 which states that wildcard certs are deprecated :) > https://tools.ietf.org/html/rfc6125#section-7.2 Only mostly deprecated; it admits of legitimate uses for them. :) Wildcards are not the best feature of the web PKI, I agree, and I wouldn't want to use them if I could think of a viable alternative. (And consider that putting domains in the CN has been deprecated since HTTPS/TLS was even a standard, back in 2000 --- yet everyone still does that.) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates
On Mon, Apr 03, 2017 at 04:17:13PM -0700, Wim Lewis wrote: > I'm trying to provision a client with a wildcard certificate[1]. I > followed the procedure outlined in [2], but I'm not receiving the > certificate I expect. The certificate's subject DN contains a > wildcard string, but the SAN does not. Since the SAN, not the > subject name, is the relevant part of the certificate [3], this > isn't the right certificate. > > What I want is a certificate with two SAN entries, a dNSName for > "blah.example.com" and another dNSName for "*.blah.example.com". > But if I request the additional SAN (by passing "-D > 'blah.example.com' -D '*.blah.example.com'" to getcert) then the > request fails: > > status: CA_UNREACHABLE > ca-error: Server at https://ipa.example.com/ipa/xml failed > request, will retry: 4001 (RPC failed at server. The > service principal for subject alt name *.blah.example.com in > certificate request does not exist). > > How do I tell FreeIPA that it is OK for it to issue a cert with an > additional SAN to my host principal? > The only way is to create a profile that hard-codes the desired SAN data, then use that profile. The observed behaviour is because FreeIPA's CSR processing checks that all SAN values present in the CSR actually correspond to the indicated subject principal(s). In your case, there is no principal that has a wildcard in its name, so the cert request gets rejected. We are not planning to change FreeIPA to support wildcard dnsNames in SAN. More commentary below. > > [1] Why am I using a wildcard certificate despite it being easy to > issue certs from FreeIPA? I'm using it with sandstorm.io, which > creates a randomly named subdomain for essentially every session. > This is a reasonable use of wildcard certificates, as I understand > it, since all of the domains are served from the same process and > no other domain can match the cert's wildcard - sandstorm owns the > dns hierarchy under its root. > Is your instance publicly hosted? Perhaps the sandstorm.io developers could support ACME/Let's Encrypt so that certs can be automatically acquired for each domain... > [2] https://www.freeipa.org/page/Howto/Wildcard_certificates > [3] See RFC6125 [B.2], based on RFC 2818, which describes what > part of the certificate the browser should look at to see if the > certificate matches the expected hostname. In short, as far as > HTTPS is concerned, if there are DNS SANs, then the subject field > of the server's certificate (and its CN) is irrelevant. > This is correct. But see also §7.2 which states that wildcard certs are deprecated :) https://tools.ietf.org/html/rfc6125#section-7.2 Thanks, Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates
I'm trying to provision a client with a wildcard certificate[1]. I followed the procedure outlined in [2], but I'm not receiving the certificate I expect. The certificate's subject DN contains a wildcard string, but the SAN does not. Since the SAN, not the subject name, is the relevant part of the certificate [3], this isn't the right certificate. What I want is a certificate with two SAN entries, a dNSName for "blah.example.com" and another dNSName for "*.blah.example.com". But if I request the additional SAN (by passing "-D 'blah.example.com' -D '*.blah.example.com'" to getcert) then the request fails: status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. The service principal for subject alt name *.blah.example.com in certificate request does not exist). How do I tell FreeIPA that it is OK for it to issue a cert with an additional SAN to my host principal? [1] Why am I using a wildcard certificate despite it being easy to issue certs from FreeIPA? I'm using it with sandstorm.io, which creates a randomly named subdomain for essentially every session. This is a reasonable use of wildcard certificates, as I understand it, since all of the domains are served from the same process and no other domain can match the cert's wildcard - sandstorm owns the dns hierarchy under its root. [2] https://www.freeipa.org/page/Howto/Wildcard_certificates [3] See RFC6125 [B.2], based on RFC 2818, which describes what part of the certificate the browser should look at to see if the certificate matches the expected hostname. In short, as far as HTTPS is concerned, if there are DNS SANs, then the subject field of the server's certificate (and its CN) is irrelevant. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
