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