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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
