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