[Freeipa-devel] FreeIPA and wildcard certificates

[Alexander Bokovoy]

On to, 09 helmi 2017, Fraser Tweedale wrote:
>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

While it is not recommended to issue wildcard certificates, it is far
from being a deprecated practice. In fact, almost all commercial CAs do
have wildcard certificate product in their portfolio. We also have seen
customers coming to use FreeIPA with wildcard certificates issued by
external CAs. This practice is not going to disappear. 


>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.
Another question would be:

- Do we need to support issuing "hostname.*.${IPA_DOMAIN}"? I.e.
  wildcard cert where a '*' character is not a leftmost label.

-- 
/ Alexander Bokovoy