On to, 09 helmi 2017, 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 
> 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 
> [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 
  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.

[1] https://tools.ietf.org/html/rfc6125#section-7.2

While it is not recommended to issue wildcard certificates, it is far
from being a deprecated practice. In fact, almost all commercial CAs do
have wildcard certificate product in their portfolio. We also have seen
customers coming to use FreeIPA with wildcard certificates issued by
external CAs. This practice is not going to disappear.

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.
Another question would be:

- Do we need to support issuing "hostname.*.${IPA_DOMAIN}"? I.e.
 wildcard cert where a '*' character is not a leftmost label.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to