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

[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. 


On Apr 3, 2017, at 6:41 PM, Fraser Tweedale  wrote:
> 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.

> 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!). 

> 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.)



-- 
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

[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.



-- 
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