Yes. In our environment, our ldap pairs are behind dumb VIPs (not involved in TLS/SSL conversation).
The cert's Subject is the VIP name, with 3 SAN entries: * subject name again (some clients have been known to ignore the Subject when SAN entry is present) * node 1 name * node 2 name
This enables the pairs to communicate directly with each other (whether slave to master VIP or masters to each other), and clients via the VIP with no SSL cert checking disabled.
Your situation is a little trickier though; it appears you're dealing with external and internal DNS names; and I suspect the external one is using an cert from a public CA. I don't know if it's a good idea to expose internal naming on that cert via the SAN names. Plus it's more expensive to get a multi-domain certificate.
The best method might be to setup a slave node who's sole purpose is to handle external queries, and it uses the external name when communicating internally too. This of course involves getting the node(s) acting as master(s) for this node to trust the CA used for the external cert. Thankfully, OpenLDAP synching is slave pulled vs master pushed, so (hopefully) you won't have to deal with either split horizon DNS or split routing.
- chris
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of lejeczek Sent: Thursday, October 17, 2013 8:50 AM To: openldap-technical@openldap.org Subject: Subject Alternative Name in TLS - does this work?
dear all
I'm trying to set a seeminglysimple setup having a box with openldap I want it to use TLS on both internal and external hostnames/IPs
openldap was set up earlier and was/is working I generate TLS certificate with SAN everything seems working fine but when I ldapsearch on external fqdn/IP (which in the certificate is the subjectAltName) search fails whereas it succeeds on internal fqdn(which is the hostname/ CN in the certificate)
error is: additional info: TLS error -8157:Certificate extension not found.
is such a scenario even possible? having very same DN being served on more than one name via TLS?
best wishes
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.