[Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

On 02/09/2017 02:12 AM, 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.

Right now, I am talking to a Solution Architect, i.e. someone who is building
GAed solutions, not developers. This is not something we would change
short-term anyway, this is how current OpenShift v2 or v3 behaves, despite the RFC.

While I understand why having certificate *.lab.example.com and using it for my
lab machines is a bad idea and increases the attack vector, I do not see it
that way for OpenShift. There, applications get URL like
"<app-dom>.myopenshift.test" and all is routed by one entity, the OpenShift
broker. So the key.cert is on one location, just serving different names that
are provisioned with OpenShift.

I can understand that issuing a new certificate for every application
provisioned by OpenShift and then renewing it complicates the design
significantly. I am trying to be creative and see if current OpenShift could
leverage FreeIPA CA and issue the broker cert, with current profile
capabilities or with small change.

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

I do not know, but I can ask if it is important for you :-)

Martin