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. >> - 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. Thanks! 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
