[Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

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]?

Thanks!

[1]
https://docs.openshift.com/container-platform/3.4/install_config/router/default_haproxy_router.html#using-wildcard-certificates
[2] https://fedorahosted.org/freeipa/ticket/3475

[Alexander Bokovoy]

Post by Martin Kosek
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.

[Fraser Tweedale]

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

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

Cheers,
Fraser

[Martin Kosek]

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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

[Fraser Tweedale]

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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. An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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 :)

Cheers,
Fraser

[Martin Kosek]

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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.

- how complex would it be to add support of Wildcard certificate support to
FreeIPA (rough scope).

Thanks,
Martin

[Fraser Tweedale]

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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
- 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.

Post by Martin Kosek
- 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

[Martin Kosek]

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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
- 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'.
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.

Post by Fraser Tweedale

Post by Martin Kosek
- 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.

Thanks!
Martin

[Fraser Tweedale]

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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
- 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'.
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/

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek
- 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.
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

[Martin Kosek]

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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
- 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'.
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.

http://blog-ftweedal.rhcloud.com/2017/02/wildcard-certificates-in-freeipa/

I knew that will be a procedure like that! :-) Thanks for writing it down.

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek
- 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.
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.

I will definitely pass this information.

As for any follow on FreeIPA side, I think it would be fine to add this
procedure as an official FreeIPA Howto, just to make sure it does not
disappear. I saw you linked it from
http://www.freeipa.org/page/HowTos
but I think it would make sense having this also on the official project wiki.

Martin

[Fraser Tweedale]

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.

Post by Fraser Tweedale
An automated solution does not yet exist but that
doesn't mean it can't be built out of what's currently GA.

Post by Martin Kosek

Post by Fraser Tweedale
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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
- 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'.
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.

http://blog-ftweedal.rhcloud.com/2017/02/wildcard-certificates-in-freeipa/

I knew that will be a procedure like that! :-) Thanks for writing it down.

Post by Fraser Tweedale

Post by Martin Kosek

Post by Fraser Tweedale

Post by Martin Kosek
- 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.
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.

I will definitely pass this information.
As for any follow on FreeIPA side, I think it would be fine to add this
procedure as an official FreeIPA Howto, just to make sure it does not
disappear. I saw you linked it from
http://www.freeipa.org/page/HowTos
but I think it would make sense having this also on the official project wiki.

I copied my blog post to the wiki (and updated the HowTos index):
https://www.freeipa.org/page/Howto/Wildcard_certificates

Cheers,
Fraser

[Alexander Bokovoy]

Post by Fraser Tweedale

Post by Alexander Bokovoy

Post by Martin Kosek
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
- 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
- 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
- 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.
[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.

Post by Fraser Tweedale
If we do go ahead with wildcard cert support in FreeIPA, some of my
- 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.