[Freeipa-devel] FreeIPA and wildcard certificates

Fri Feb 10 09:37:08 UTC 2017

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