[Freeipa-devel] FreeIPA and wildcard certificates

Fraser Tweedale ftweedal at redhat.com
Thu Feb 9 01:12:00 UTC 2017


On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
> On ke, 08 helmi 2017, Martin Kosek wrote:
> > Hi Fraser and the list,
> > 
> > I recently was in a conversation about integrating OpenShift with FreeIPA. One
> > of the gaps was around generating a wildcard certificate by FreeIPA that will
> > be used in the default OpenShift router for applications that do not deploy own
> > certificates [1].
> > 
> > Is there any way that FreeIPA can generate it? I was thinking that uploading
> > some custom certificate profile in FreeIPA may let us get such certificate...
> > Or is the the only way we can add it by adding a new RFE in FreeIPA, tracked in
> > [2]?
> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
> certificates to be issued:
> 
> - we ensure subject 'cn' of the certificate matches a Kerberos principal
>   specified in the request
> 
> - we validate that host object exists in IPA when the Kerberos
>   principal is host/...
> 
> We could lift off these two limitations for 'cn=*,$suffix' but there is
> still a need to apply proper ACLs when issuing the cert -- e.g. some
> object has to be used for performing access rights check. The wildcard
> certificate does not need to be stored anywhere in the tree, but a
> check still needs to be done.
> 
> For example, for Kerberos PKINIT certificate which is issued to KDC we
> don't store public certificate in LDAP either but we do two checks:
> - a special KDC certificate profile is used to issue the cert
> - a special hostname check is done so that only IPA masters are able to
>   request this certificate
> 
> For the wildcard certificate I think we could have following:
> - use a separate profile for the wildcard, associated with a sub-CA
> - hardcode CN default in the profile to always be 'CN=*, O=$SUB_CA_SUBJECT' so that
>   actual certificate ignores requested CN.
> - a special check to be done so that only wildcard-based subject
>   alternative names can be added to a wildcard certificate request
> - all Kerberos principal / hostname checks are skipped.
> - actual ACL check is done by CA ACL.
> 
Issuing wildcard certs is a deprecated practice[1].  I am not
dismissing the needs of OpenShift (or PaaS/IaaS solutions in
general) but I'd like to have a discussion with them about how
they're currently dealing with certs and whether a different
direction other than wildcard certs is feasible.  Martin, who should
I reach out to?  Feel free to copy them into this discussion.

[1] https://tools.ietf.org/html/rfc6125#section-7.2

If we do go ahead with wildcard cert support in FreeIPA, some of my
initial questions are:

- For the OpenShift use case, what is the "parent" domain name and
  is it the same as the IPA domain name?  Is it a subdomain of the
  IPA domain name?

- Do we need to support issuing "*.${IPA_DOMAIN}"? i.e. wildcard
  cert under entire IPA domain name.

- Do we need to support issuing "*.${IPA_HOSTNAME}"?  i.e. wildcard
  certs under names of IPA host principals.

Cheers,
Fraser




More information about the Freeipa-devel mailing list