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

[Fraser Tweedale]

On Wed, Apr 05, 2017 at 10:38:48PM -0700, Wim Lewis wrote:
> 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. 
> 
Suffice to say: this is not a supported or recommended approach :)

> 
> On Apr 3, 2017, at 6:41 PM, Fraser Tweedale <ftweedal at redhat.com> 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.
> 
Have a look at:
https://www.redhat.com/archives/pki-users/2014-January/msg00005.html
Based on the example there you would change a couple of config.

  policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName
  policyset.serverCertSet.9.default.params.subjAltExtPattern_0=*.blah.exmaple.com

The rest of the profile config could be a direct copy of
caIPAserviceCert, although it would be sensible to remote the
'userExtDefault' component, which is used to copy a SAN extension
from the CSR, would could cause a conflict.

> > 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.
> 
Right.  Let's Encrypt does rate limit per registered domain (max 20
per week according to [1]).  So that would seem to be too low for
your use case.

[1] https://letsencrypt.org/docs/rate-limits/

> 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!). 
> 
If you trust the IPA CA, you could create a sub-CA under it, export
it, and use it with whatever software can meet your needs.

But this leads me to the question: are you using FreeIPA already and
trying to work out how to fit the Sandstorm use case into it?  Or
are you just looking for a solution for Sandstorm?

> > 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.
> 
The fact that you are looking at FreeIPA suggests that you will be
anchoring your trust at some private CA (not a publicly trusted CA).
If that is the case, then you always have the viable option, "build
the software you need".  It may not exist OOTB but AFAICS there is
nothing fundamentally difficult about your use case.

> (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.)
> 
Sure, but do not hold it against us if we follow the standards :)

Thanks,
Fraser