I thought it would rather be a common situation
CA for the slapd box is on a host that belongs to the same
internal domain slapd host belongs
ca.local.domain
slapd.local.domain
and, I was hoping ca.local.domain can issue a certificate
for both slapd.local.domain & slap.public.external
slapd.local.domain is the actual host name for the box,
slap.public.external easy to guess is slapd box's second
interface
slapd is redhat's openldap-servers-2.4.23-26.el6_3.2.x86_64,
I hoped since slapd does not say a bad word about TLS cert
with SAN it's tool would be fine too
I'll keep fiddling with it, I hoped someone has gone through
such a scenario and successfully
regards
On 10/17/2013 05:18 PM, Chris Jacobs wrote:
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: [email protected]
[mailto:[email protected]] On Behalf Of lejeczek
Sent: Thursday, October 17, 2013 8:50 AM
To: [email protected]
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.
