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:

        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 

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to