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

[Fraser Tweedale]

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