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
