On Wed, Feb 22, 2017 at 10:17:32AM +0100, Martin Kosek wrote: > 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. > I copied my blog post to the wiki (and updated the HowTos index): https://www.freeipa.org/page/Howto/Wildcard_certificates
Cheers, Fraser -- 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
