[Freeipa-devel] FreeIPA and wildcard certificates

Wed Feb 22 09:17:32 UTC 2017

On 02/20/2017 06:03 AM, Fraser Tweedale wrote:
> On Fri, Feb 10, 2017 at 11:48:39AM +0100, Martin Kosek wrote:
>> On 02/10/2017 10:37 AM, Fraser Tweedale wrote:
>>> On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote:
>>>> On 02/09/2017 10:44 PM, Fraser Tweedale wrote:
>>>>> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote:
>>>>>> 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.
>>>>>>
>>>>> I believe OpenShift supports per-application certificates (i.e. when
>>>>> app developers/maintainers supply their own cert for a custom
>>>>> domain).  So it might be possible in v2 or v3 to provision a cert
>>>>> for every app.
>>>>
>>>> Right, it supports this. But then issuing the certificate and renewal is a
>>>> responsibility of app developer, AFAIK. I do not think if OpenShift has all the
>>>> needed hooks to do this automatically and call certmonger for example.
>>>>
>>>> TLDR; adding a support of certmonger and issuing a certificate for every new
>>>> application is a whole another degree of complexity than just issuing a
>>>> Wildcard certificate for the router. I am not saying it should not be done, I
>>>> am just saying that being able to generate a wildcard certificate with FreeIPA
>>>> would let us integrate with OpenShift much better than now and with (hopefully)
>>>> low effort involved, i.e. faster.
>>>>
>>>>> An automated solution does not yet exist but that
>>>>> doesn't mean it can't be built out of what's currently GA.
>>>>>
>>>>>>> [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 :-)
>>>>>>
>>>>> It's important to know what I actually need to do if we proceed with
>>>>> implementing this :)
>>>>
>>>> We do not need to jump on implementing it right away, you already have a lot on
>>>> your plate. Right now, I must just want to know:
>>>>
>>>> - is there any way how I can generate wildcard cert with current FreeIPA, using
>>>> a custom certificate profile. I assume the answer is no.
>>>>
>>> I have an idea.
>>>
>>> - Assume there exists a FreeIPA host `foo.example.com', the "parent"
>>>   domain name for the desired wildcard name `*.foo.example.com'.
>>>
>>> - Create a profile with the config:
>>>
>>>     policyset.serverCertSet.<N>.constraint.class_id=subjectNameConstraintImpl
>>>     policyset.serverCertSet.<N>.constraint.name=Subject Name Constraint
>>>     policyset.serverCertSet.<N>.constraint.params.accept=true
>>>     policyset.serverCertSet.<N>.constraint.params.pattern=CN=[^,]+,.+
>>>     policyset.serverCertSet.<N>.default.class_id=subjectNameDefaultImpl
>>>     policyset.serverCertSet.<N>.default.name=Subject Name Default
>>>     policyset.serverCertSet.<N>.default.params.name=CN=*.$request.req_subject_name.cn$, o=EXAMPLE.COM
>>>
>>> - Set up CA ACLs to constrain use of this profile for issuance only
>>>   to hosts for which a wildcard cert *under* their hostname is
>>>   allowed.
>>>
>>> - Issue wildcard cert.
>>>
>>> I'm not 100% sure if that last directive from the snippet above is
>>> valid.  Worth a shot.
>>
>> This is exactly what I was looking for, as a workaround! Do you think you would
>> be able to try it (not necessarily right now, but in several days)? Just so
>> that we know it would work.
>>
> It works.  I wrote it up in a blog post:
> http://blog-ftweedal.rhcloud.com/2017/02/wildcard-certificates-in-freeipa/

I knew that will be a procedure like that! :-) Thanks for writing it down.

>>>> - how complex would it be to add support of Wildcard certificate support to
>>>> FreeIPA (rough scope).
>>>>
>>> It really depends on the answers to my earlier questions :)  Need to
>>> know *exactly* what is needed for OpenShift in terms of how the
>>> domain(s) to include in the cert relate to IPA domain or
>>> host/service principals defined therein.
>>
>> We should not make feature too specific to OpenShift anyway, so I do not think
>> the answers to these questions need to come from OpenShift, but rather from our
>> understanding of how to make this feature useful for FreeIPA users.
>>
>> But if you check OpenShift documentation:
>> https://docs.openshift.com/container-platform/3.4/install_config/router/default_haproxy_router.html#using-wildcard-certificates
>> you will see that the domain for the wildcard is configurable. So AFAIK, the
>> OpenShift may join a realm EXAMPLE.COM and have the wildcard cert for
>> '*.cloudapps.example.com.
>>
> After my exploration of what we can do with FreeIPA, I'd now be
> surprised if we need to do anything else at all, besides perhaps
> some official doc e.g. a KBase article.
> 
> Please pass the info along and see if the OpenShift folks are happy
> with what they can do with a custom profile.

I will definitely pass this information.

As for any follow on FreeIPA side, I think it would be fine to add this
procedure as an official FreeIPA Howto, just to make sure it does not
disappear. I saw you linked it from
http://www.freeipa.org/page/HowTos
but I think it would make sense having this also on the official project wiki.

Martin