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. > [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 :-) 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