Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
Cheers, Fraser
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
Christian
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
Simo.
On Tue, 2020-09-29 at 09:44 -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
So much for my evil plan to discuss this first off list :-D
Simo.
Simo.
-- Simo Sorce RHEL Crypto Team Red Hat, Inc
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
Simo.
SRVName in the certificate mitigates this security issue, if the client validates SRVName per RFC 6125. But FreeIPA does not yet support issuing certs with SRVName. I have an experimental branch but there are some issues to resolve.
Cheers, Fraser
On Wed, 2020-09-30 at 16:04 +1000, Fraser Tweedale wrote:
On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
Simo.
SRVName in the certificate mitigates this security issue, if the client validates SRVName per RFC 6125. But FreeIPA does not yet support issuing certs with SRVName. I have an experimental branch but there are some issues to resolve.
Would be really cool to support indeed, as that definitely resolve issues as long as the CA properly verifies ownership of the SRV Name before granting it in certs. Any thought on how we could support this with ACME ? I guess we'd need an additional test ?
Simo.
On Wed, Sep 30, 2020 at 09:43:29AM -0400, Simo Sorce wrote:
On Wed, 2020-09-30 at 16:04 +1000, Fraser Tweedale wrote:
On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
Hi guys,
I have 12 freeipa servers deployed with integrated DNS and CA (realm and domain int.example.com).
I would like to make a DNS round-robin, for instance: request ldap.int.example.com and forward for one of the servers and also an external domain ldap.example.com
The problem is with the certificate, the TLS handshake fails because there's no alternative name with ldap.int.example.com or ldap.example.com.
I read the redhat documentation about certificate manipulation, but I got very confused in fact how it works.
How can I do that? Are there another recommendation?
Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
Simo.
SRVName in the certificate mitigates this security issue, if the client validates SRVName per RFC 6125. But FreeIPA does not yet support issuing certs with SRVName. I have an experimental branch but there are some issues to resolve.
Would be really cool to support indeed, as that definitely resolve issues as long as the CA properly verifies ownership of the SRV Name before granting it in certs. Any thought on how we could support this with ACME ?
Good question. There has been limited discussion of SRVName in the ACME WG and related circles (Let's Encrypt / boulder development). The dicsussion usually ends at "CA/B Forum prohibits SRVName in certificates, therefore we do not want this complexity for something we cannot use". But there are important uses for SRVName outside web Web PKI. And a robust spec for doing SRVName validation might be just what is needed for CA/B Forum to finally accept SRVName in the Baseline Requirements.
I can think of a couple of ways to validate SRVName in ACME.
1. Extend the "dns-01" challenge[1]. When validing the SRVName
_service.example.com
the TXT record containing the authorisation, to be provisioned by the ACME client, would be something like:
- _acme-challenge._service._tcp.example.com, or - _service._tcp._acme-challenge.example.com, or - something else along these lines
2. Extend the "tls-alpn-01" challenge[2]. When validating the SRVName
_service.example.com
Query SRV records for _service._tcp.example.com. For each result, initiate a TLS connection to the target on the given port. Validation proceeds as per[2], except that the SAN extension in the self-signed certificate must contain a single SRVName that matches the name being validated.
Finally, because an SRV record can have many targets, for efficiency the ACME representation of an SRVName identifier could contain an (optional) binding or hint to a specific target. e.g. the identifier specification
{ "type": "srv", , "value": "_service.example.com", , "target": "service01.example.com:1021" }
would restrict the ACME server to contacting only the specified target (which must be a target in the SRV records).
[1] https://tools.ietf.org/html/rfc8555#section-8.4 [2] https://tools.ietf.org/html/rfc8737
Should I start an Internet-Draft? :)
Validating SRVName in FreeIPA cert-request is another problem entirely. Some "target" relationship needs to be established between the service principal requesting the certificate (e.g. "service/service01.example.com@REALM") and some object representing the abstract service (e.g. service principal "service/example.com@REALM"). It can probably be done using 'managedBy' attribute.
Alternatively we could validate using records in IPA integrated DNS like we do for IPAddressName validation. It would need to be discussed more, and the approach agreed and written into a design doc.
Cheers, Fraser
On Thu, 2020-10-01 at 11:46 +1000, Fraser Tweedale wrote:
On Wed, Sep 30, 2020 at 09:43:29AM -0400, Simo Sorce wrote:
On Wed, 2020-09-30 at 16:04 +1000, Fraser Tweedale wrote:
On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users wrote:
On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote: > Hi guys, > > I have 12 freeipa servers deployed with integrated DNS and CA > (realm and domain int.example.com). > > I would like to make a DNS round-robin, for instance: request > ldap.int.example.com and forward for one of the servers and also > an external domain ldap.example.com > > The problem is with the certificate, the TLS handshake fails > because there's no alternative name with ldap.int.example.com or > ldap.example.com. > > I read the redhat documentation about certificate manipulation, > but I got very confused in fact how it works. > > How can I do that? Are there another recommendation? > Hello Willie,
It is not supported. With some effort you could create the necessary objects and relationship in FreeIPA to permit issuance of such a certificate, then you could modify the certmonger tracking request (on every server) to request a certificate with those SANs. But the tracking request modifications would eventually be lost during ipa-server-upgrade (FreeIPA will see that the tracking request doesn't match expectations and replace it).
A possible alternative approach (I haven't tested it yet) is if you discover the LDAP servers via SRV records, i.e. _ldaps._tcp.int.example.com. This would give "round robin" (actually service weighting but you get the idea) to all the LDAP servers in the topology. I'd have to check if openldap client performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request https://github.com/python-ldap/python-ldap/issues/178 contains more information on the topic. I have recently implemented a new feature that would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly use the SRV address. Instead you perform a SRV lookup which gives you a list of hostnames with weights and priorities. An LDAP client connects to the hostnames and uses the hostname to verify the identity of the certificate.
This is cool but also problematic wrt security unless DNSSEC is used, as it is relatively easy to spoof a SRV record reply to point the client to an attacker controlled server.
Simo.
SRVName in the certificate mitigates this security issue, if the client validates SRVName per RFC 6125. But FreeIPA does not yet support issuing certs with SRVName. I have an experimental branch but there are some issues to resolve.
Would be really cool to support indeed, as that definitely resolve issues as long as the CA properly verifies ownership of the SRV Name before granting it in certs. Any thought on how we could support this with ACME ?
Good question. There has been limited discussion of SRVName in the ACME WG and related circles (Let's Encrypt / boulder development). The dicsussion usually ends at "CA/B Forum prohibits SRVName in certificates, therefore we do not want this complexity for something we cannot use". But there are important uses for SRVName outside web Web PKI. And a robust spec for doing SRVName validation might be just what is needed for CA/B Forum to finally accept SRVName in the Baseline Requirements.
I can think of a couple of ways to validate SRVName in ACME.
Extend the "dns-01" challenge[1]. When validing the SRVName
_service.example.com
the TXT record containing the authorisation, to be provisioned by the ACME client, would be something like:
- _acme-challenge._service._tcp.example.com, or
- _service._tcp._acme-challenge.example.com, or
- something else along these lines
Extend the "tls-alpn-01" challenge[2]. When validating the SRVName
_service.example.com
Query SRV records for _service._tcp.example.com. For each result, initiate a TLS connection to the target on the given port. Validation proceeds as per[2], except that the SAN extension in the self-signed certificate must contain a single SRVName that matches the name being validated.
Finally, because an SRV record can have many targets, for efficiency the ACME representation of an SRVName identifier could contain an (optional) binding or hint to a specific target. e.g. the identifier specification
{ "type": "srv", , "value": "_service.example.com", , "target": "service01.example.com:1021" }
would restrict the ACME server to contacting only the specified target (which must be a target in the SRV records).
[1] https://tools.ietf.org/html/rfc8555#section-8.4 [2] https://tools.ietf.org/html/rfc8737
Should I start an Internet-Draft? :)
I think this is a neat idea, count me in for help if you want to go in this direction, I've worked on RFCs before and familiar with the process.
Validating SRVName in FreeIPA cert-request is another problem entirely. Some "target" relationship needs to be established between the service principal requesting the certificate (e.g. "service/service01.example.com@REALM") and some object representing the abstract service (e.g. service principal "service/example.com@REALM"). It can probably be done using 'managedBy' attribute.
We could, or not, we may use the same approach you are proposing for ACME as well.
Alternatively we could validate using records in IPA integrated DNS like we do for IPAddressName validation. It would need to be discussed more, and the approach agreed and written into a design doc.
We need to also care for the case where IPA is not, in fact, the DNS server, for example in a situation where IPa manages the servers in a subdomain like ipa.example.com, but the service name is exposed on the parent domain (example.com) managed in some other DNS infrastructure.
In the end the IPA CA admins should always be able to get a cert out, for less privileged user you may want a more constrained check to escalate to admins in the worst case.
HTH, Simo.
freeipa-users@lists.fedorahosted.org
-
Christian Heimes -
Fraser Tweedale -
Simo Sorce -
Willie Lima