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

Wim Lewis wiml at omnigroup.com
Mon Apr 3 23:17:13 UTC 2017


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.






More information about the Freeipa-users mailing list