--On Friday, October 18, 2013 8:52 AM +0100 lejeczek peljasz@yahoo.co.uk wrote:

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

Get a current release that is linked to OpenSSL, not the MozNSS garbage RH links to.

You may want to try http://ltb-project.org/wiki/download#openldap

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

On 10/18/2013 10:41 AM, Christian Kratzer wrote:

Hi,

On Thu, 17 Oct 2013, lejeczek wrote:

...

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?

If this is what you are looking for I can confirm that I have a setup with ldaps:// and ldap:// with TLS that uses subjectAltNames in the certificates.

Relevant parts of the x509 cert with customer name obfuscated

We have this on one server:

    Subject: C=XX, ST=State, L=City, O=Company, 

CN=ldap1.example.org X509v3 Subject Alternative Name: DNS:ldap1.example.org, DNS:ldap1, DNS:ldap-cluster.example.org, DNS:ldap-cluster

We have this on the other server:

    Subject: C=XX, ST=State, L=City, O=Company, 

CN=ldap2.example.org X509v3 Subject Alternative Name: DNS:ldap2.example.org, DNS:ldap2, DNS:ldap-cluster.example.org, DNS:ldap-cluster

We can connect to ldap-cluster.example.org just fine independent of to which server the load balancer directs the tcp connection to.

This is using openldap-2.4.36

hi Christian

my case is, well should be a lot more simpler, one box with

slapd.local.domain slap.public.external

and this one host I would like to be able to search through on/via both hostnames/IPs with TLS so I issue myself and sign a certificate, CA issuer is CA.local.domain

Subject: .......... CN=slapd.local.domain/email......... and X509v3 Subject Alternative Name: DNS:slap.public.external, IP Address:ex.te.rn.al

ldapsearch -h slap.public.external -D cn=manager,dc=local,dc=domain .... result: TLS: hostname (slap.public.external) does not match common name in certificate (slapd.local.domain). TLS: can't connect: TLS error -8157:Certificate extension not found.. ldap_start_tls: Connect error (-11) additional info: TLS error -8157:Certificate extension not found.

whereas: ldapsearch -h slap.local.domain -D cn=manager,dc=local,dc=domain works fine could it be tools from be openldap-clients, a bug? Apache's ldap toolkit for Eclipse seems to work and connects to slap.public.external

??

btw, being novice with openssl, is there a way to print extensions thus SAN of a certificate? I can print and see it on the request.

regards

Greetings Christian

On 10/18/2013 11:59 AM, Christian Kratzer wrote:

Hi,

On Fri, 18 Oct 2013, lejeczek wrote:

<snipp/> > hi Christian > > my case is, well should be a lot more simpler, one box with > > slapd.local.domain > slap.public.external > > and this one host I would like to be able to search > through on/via both hostnames/IPs with TLS > so I issue myself and sign a certificate, CA issuer is > CA.local.domain > > Subject: .......... CN=slapd.local.domain/email......... > and > X509v3 Subject Alternative Name: > DNS:slap.public.external, IP > Address:ex.te.rn.al > > ldapsearch -h slap.public.external -D > cn=manager,dc=local,dc=domain .... > result: > TLS: hostname (slap.public.external) does not match > common name in certificate (slapd.local.domain). > TLS: can't connect: TLS error -8157:Certificate extension > not found.. > ldap_start_tls: Connect error (-11) > additional info: TLS error -8157:Certificate extension > not found. > > whereas: > ldapsearch -h slap.local.domain -D > cn=manager,dc=local,dc=domain > works fine > could it be tools from be openldap-clients, a bug? > Apache's ldap toolkit for Eclipse seems to work and > connects to slap.public.external

this should work. It does in two separate setups that I maintain.

Which version is your openldap client ?

whole toolkit is Redhats 2.4.23-31.el6.x86_64 on RHEL 6.4

Have you configured the CA certificate for trust ? I have following in my /usr/local/etc/openldap/ldap.conf to configure the CA certificate:

for ldapsearch I use args in line for the command, also debug it and see that wanted certificate is pulled in

[ck@ldaptest1]$ cat ~ldap/ldap.conf
BASE dc=example,dc=org
URI ldap://ldaptest1.cksoft.de
TLS_CACERT 

/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert

TLS_REQCERT demand

...

btw, being novice with openssl, is there a way to print extensions thus SAN of a certificate? I can print and see it on the request.

use following to dump the certificate:

openssl s_client -text -in CERT.pem

and no such things for s_clients in the toolkit version as above, I normally view a certificate with:

openssl x509 -issuer -subject -enddate -noout -text -in CERT.pem -- and I cannot see subjectAltNames

how could it be, given above is the right way to get all relevant info of a certificate that request has subjectAltNames but actual certificate misses it?

You should see the subjectAltNames.

If not your certificate is broken.

Greetings Christian

On 10/18/2013 02:37 PM, Christian Kratzer wrote:

Hi,

On Fri, 18 Oct 2013, lejeczek wrote:

<snipp/> >> use following to dump the certificate: >> >> openssl s_client -text -in CERT.pem > and no such things for s_clients in the toolkit version > as above, > I normally view a certificate with: > > openssl x509 -issuer -subject -enddate -noout -text -in > CERT.pem -- and I cannot see subjectAltNames > > how could it be, given above is the right way to get all > relevant info of a certificate that request has > subjectAltNames but actual certificate misses it?

I totally goofed up the openssl command line. It is of course:

 openssl x509 -text -in CERT.pem

If you do not see the subjectAltNames there then they are not in the certificate.

How did you get those requests signed ?

ok, above doesn't get me much more than what was in my command line but still no! subjectAltNames, I had a similar thought to what Quanah suggested but first, before I try different ssl toolchain I shall assume it is me messing thing up. I definitively have subjectAltNames in my request, the I sign:

openssl x509 -req -extensions v3_req -days 365 -in .... -signkey ... -out ...

where is the problem?

regards

Greetings Christian

that was me, the way I tried to sing certificate were... incorrect

apologies and great and many thanks to everybody

I can now ldapsearch on both slapd.domain.local and slap.domain.external with -ZZZ, all good (only cannot confirm if CN has to be repeated in subjectAltName as per Olo's tip, currently it IS repeatedin my cert) last bit is WPMU Ldap Auth on Wordpress 3.6.1 which is somehow not working :) hmm..

regards

On 10/21/2013 10:06 AM, Christian Kratzer wrote:

Hi,

On Mon, 21 Oct 2013, lejeczek wrote:

...

ok, above doesn't get me much more than what was in my command line but still no! subjectAltNames, I had a similar thought to what Quanah suggested but first, before I try different ssl toolchain I shall assume it is me messing thing up. I definitively have subjectAltNames in my request, the I sign:

Do you have them in the resulting request or certificate or do you have them ?

If you do have them then you should see them in the resulting request or certificate file.

...

openssl x509 -req -extensions v3_req -days 365 -in .... -signkey ... -out ...

where is the problem?

where are you specifying the actual subjectAltNames ?

I use following in the specific openssl.cnf I use for signing.

[ v3_req ] subjectAltName = $ENV::ALTNAME

I then supply the subjectAltnames and the COMMONNAME using the environment:

env COMMONNAME=$fqdn ALTNAME=$subjectAltName openssl req -new -nodes -keyout $CERTDIR/$name.key -out $CERTDIR/$name.csr -config $CONFIG

Greetings Christian

2013/10/21 Howard Chu hyc@symas.com

lejeczek wrote:

...

that was me, the way I tried to sing certificate were... incorrect

apologies and great and many thanks to everybody

I can now ldapsearch on both slapd.domain.local and slap.domain.external with -ZZZ, all good (only cannot confirm if CN has to be repeated in subjectAltName as per Olo's tip, currently it IS repeatedin my cert)

No. The CN does not need to be repeated, anyone who says so is wrong. Other libraries (e.g. old Solaris/Sun/Mozilla LDAP) may have required this but they are defective and obsolete. The Mozilla LDAP SDK has been abandoned, and Solaris 11 now bundles OpenLDAP.

The CN has to be repeated. Newer libraries ignore anything contained in the CN if the SAN is populated. Antique PKI usages use CN to store FQDN and/or IP adresses (which is bad in itself), and this can't work with NameConstraints.

See RFC2830 (section 3.6) and RFC4513 (section 3.1.3) for LDAP, see RFC2818 (section 3.1) for HTTP, see RFC6125 for a broader view. Then see browsers root programs and CABForum Baseline Requirements (sections 9.2.1 and 9.2.2) for rules applied to public CAs (and reflected in the corresponding TLS toolkits).

Am Fri, 18 Oct 2013 14:30:35 +0100 schrieb lejeczek peljasz@yahoo.co.uk:

On 10/18/2013 11:59 AM, Christian Kratzer wrote:

...

Hi,

On Fri, 18 Oct 2013, lejeczek wrote:

<snipp/> > hi Christian > > my case is, well should be a lot more simpler, one box with > > slapd.local.domain > slap.public.external > > and this one host I would like to be able to search > through on/via both hostnames/IPs with TLS > so I issue myself and sign a certificate, CA issuer is > CA.local.domain > > Subject: .......... CN=slapd.local.domain/email......... > and > X509v3 Subject Alternative Name: > DNS:slap.public.external, IP > Address:ex.te.rn.al > > ldapsearch -h slap.public.external -D > cn=manager,dc=local,dc=domain .... > result: > TLS: hostname (slap.public.external) does not match > common name in certificate (slapd.local.domain). > TLS: can't connect: TLS error -8157:Certificate extension > not found.. > ldap_start_tls: Connect error (-11) > additional info: TLS error -8157:Certificate extension > not found. > > whereas: > ldapsearch -h slap.local.domain -D > cn=manager,dc=local,dc=domain > works fine > could it be tools from be openldap-clients, a bug? > Apache's ldap toolkit for Eclipse seems to work and > connects to slap.public.external

this should work. It does in two separate setups that I maintain.

Which version is your openldap client ?

whole toolkit is Redhats 2.4.23-31.el6.x86_64 on RHEL 6.4

...

Have you configured the CA certificate for trust ? I have following in my /usr/local/etc/openldap/ldap.conf to configure the CA certificate:

for ldapsearch I use args in line for the command, also debug it and see that wanted certificate is pulled in

...

[ck@ldaptest1]$ cat ~ldap/ldap.conf
BASE dc=example,dc=org
URI ldap://ldaptest1.cksoft.de
TLS_CACERT 

/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert

TLS_REQCERT demand

...

btw, being novice with openssl, is there a way to print extensions thus SAN of a certificate? I can print and see it on the request.

use following to dump the certificate:

openssl s_client -text -in CERT.pem

and no such things for s_clients in the toolkit version as above, I normally view a certificate with:

openssl x509 -issuer -subject -enddate -noout -text -in CERT.pem -- and I cannot see subjectAltNames

how could it be, given above is the right way to get all relevant info of a certificate that request has subjectAltNames but actual certificate misses it?

You are requesting just a reduced set of data,

openssl x509 -text -noout -in CERT.pem will present all relevant data.

-Dieter

Aleksander Dzierżanowski wrote:

On Fri, Oct 18, 2013 at 11:25:59AM +0100, lejeczek wrote:

...

[...]

...

my case is, well should be a lot more simpler, one box with

slapd.local.domain slap.public.external

and this one host I would like to be able to search through on/via both hostnames/IPs with TLS so I issue myself and sign a certificate, CA issuer is CA.local.domain

Subject: .......... CN=slapd.local.domain/email......... and X509v3 Subject Alternative Name: DNS:slap.public.external, IP Address:ex.te.rn.al

Please add "slapd.local.domain" also to SAN and problem will be fixed.

Nonsense. Unnecessary.