[Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates

[Wim Lewis]

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.

[Fraser Tweedale]

Post by Wim Lewis
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
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.

Post by Wim Lewis
[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...

Post by Wim Lewis
[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

[Wim Lewis]

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.

Post by Fraser Tweedale
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.

Post by Fraser Tweedale
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!).

Post by Fraser Tweedale
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.)

[Fraser Tweedale]

Post by Wim Lewis
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 :)

Post by Wim Lewis

Post by Fraser Tweedale
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/msg00005.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.

Post by Wim Lewis

Post by Fraser Tweedale
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/

Post by Wim Lewis
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?

Post by Wim Lewis

Post by Fraser Tweedale
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.

Post by Wim Lewis
(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