# using a  godaddy SSL cert with openLDAP



## bluethundr (Nov 25, 2010)

Hello FreeBSD,

 I am trying to setup a Godaddy turbo SSL certificate with an openLDAP 2.4 server under FreeBSD 8.1.




```
[root@LBSD2:/usr/home/bluethundr]#pkg_info | grep openldap
openldap-sasl-client-2.4.23 Open source LDAP client implementation with SASL2 support
openldap-sasl-server-2.4.23 Open source LDAP server implementation
```


I was attempting to use this guide:

OpenLDAP with a Go Daddy â€œTurbo SSL Secure Certificateâ€

I have setup the certificate chain in my slapd.conf like so:


```
[root@LBSD2:/usr/home/bluethundr]#grep -i tls /usr/local/etc/openldap/slapd.conf## TLS options for slapd
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile  /usr/local/etc/openldap/cacerts/LBSD2.example.com.crt
TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.pem
TLSCACertificateFile  /usr/local/etc/openldap/cacerts/sf_issuing.crt
```

I have tried each of the following certs with no luck in getting my cert to talk to it's CA:


```
-r--r-----  1 root  ldap        2604 Nov 25 11:37 ca_bundle.crt
-r--r-----  1 root  ldap        4604 Nov 24 18:57 gd_bundle.crt
-r--r-----  1 root  ldap        1537 Nov 25 02:00 sf_issuing.crt
```

and I get the same result for each when I attempt to connect to SSL on the LDAP server:


```
[root@LCENT01:~]#openssl s_client -connect ldap.example.com:389 -showcerts -CAfile sf_issuing.crt
13730:error:02001002:system library:fopen:No such file or directory:bss_file.c:122:fopen('sf_issuing.crt','r')
13730:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125:
13730:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:279:
CONNECTED(00000003)
13730:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
```

And this is the result of an anonymous ldapsearch on the server


```
ldapsearch -h ldap.example.com -d -1 -ZZ "dc=example,dc=com"

TLS certificate verification: depth: 0, err: 20, subject: /O=LBSD2.example.com/OU=Domain Control Validated/CN=LBSD2.example.com, issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
TLS certificate verification: Error, unable to get local issuer certificate
tls_write: want=7, written=7
  0000:  15 03 01 00 02 02 30                               ......0           
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_perror
ldap_start_tls: Connect error (-11)
	additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```

It seems to indicate that it can't talk to it's CA...

does anyone have any suggestions on how to make this work?

thanks!


----------



## bluethundr (Nov 28, 2010)

*openLDAP and GoDaddy TLS Certs*

Hello FreeBSD

 Here is some more info on the problem...

> As mentioned in my previous mail, there is no need to specify >TLSCACertificateFile in slapd.conf unless your server will request client >certificate for authentication. Nor is there any point in trying multiple >files, you can concatenate the CA certificates into a single file.

I have removed TLSCACertificateFile form slapd and now recognize that this directive is only needed on the client side. Thanks for clueing me into that. 

And here is my /etc/ldap.conf file on on the CentOS 5.5 client:


```
[root@VIRCENT03:~]#cat /etc/ldap.conf
host 192.168.1.44
base dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
TLS_CACERT /etc/openldap/cacerts/gd_sf_all.crt
```

And here are the contents of the cacerts directory on the CentOS 55 client:


```
[root@VIRCENT03:~]#ls -l /etc/openldap/cacerts/
total 36
-r--r--r-- 1 root root 27529 Nov 28 12:10 all.crt
lrwxrwxrwx 1 root root     7 Nov 28 12:20 b737b221.0 -> all.crt
```

And this is the way that nsswitch is setup on the CentOS client:


```
passwd:     files ldap
shadow:     files ldap
group:      files ldap
sudoers:    ldap
```

  I have revised the location of the cert files on the server noted in slapd.conf in order to separate out the certs from the cacerts. This is just to organize things a little more neatly. 


```
## TLS options for slapd
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile  /usr/local/etc/openldap/certs/slapd.crt
TLSCertificateKeyFile /usr/local/etc/openldap/certs/slapd.pem
```

And here are the contents of the  /usr/local/etc/openldap/certs directory, also on the server that is referenced in the TLS lines in slapd.conf:


```
-r--r--r--  1 root  ldap  2309 Nov 26 18:52 LBSD2.summitnjhome.com.crt
dr--r--r--  3 root  ldap   512 Nov 28 03:32 bak
drwxr-xr-x  2 root  ldap   512 Nov 28 03:26 cacerts
-r--r--r--  1 root  ldap  2309 Nov 26 18:53 slapd.crt
-r--r--r--  1 root  ldap  1781 Nov 26 18:36 slapd.csr
-r--r--r--  1 root  ldap  3311 Nov 26 18:35 slapd.key
-r--r--r--  1 root  ldap  3243 Nov 26 18:54 slapd.pem
```

Here is the location of the cacert file on the server that the /etc/ldap.conf file on the client references;


```
LBSD2# ls -l /usr/local/etc/openldap/certs/cacerts

-r--r--r--  1 root  ldap  27529 Nov 28 15:49 all.crt
```

The all.crt file is the result of concatenating these files together:


```
all.crt                    gdroot-g2.crt              sf_issuing.crt
ca_bundle.crt        sf_bundle.crt              sfroot-g2.crt
gd_bundle.crt        sf-class2-root.crt         sfsroot.crt
gd-class2-root.crt   sf_cross_intermediate.crt  sfsroot-g2.crt
gd_intermediate.crt  sf_intermediate.crt
```

Here is where the testing begins:


```
[root@VIRCENT03:~]#openssl s_client -connect LBSD2.summitnjhome.com:389 -showcerts -CAfile /usr/local/etc/openldap/certs/cacerts/all.crt
10073:error:02001002:system library:fopen:No such file or directory:bss_file.c:122:fopen('/usr/local/etc/openldap/certs/cacerts/all.crt','r')
10073:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125:
10073:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:279:
CONNECTED(00000003)
10073:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

CONNECTED(00000003)
10065:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
```


As you can see I have provided openssl the full path to the all.crt file on the server and am still receiving a handshake failure. It looks like openssl s_client is claiming that the all.crt file isn't there when clearly it is!

> No. I assume that your hostname is the CN indicated above, so your -h is >not the issue. When you do -ZZ then ldapsearch will fail if it cannot  >validate the certificate. You can try with a single -Z to see if it works.

Yes the hostname is in the CN of the cert file. So I agree that -h is not the issue. 

 If I do an ldapsearch from the CentOS client it claims that it can't verify the certificate:


```
[root@VIRCENT03:~]#ldapsearch -h LBSD2.summitnjhome.com -b "dc=summitnjhome,dc=com" -Z -D "cn=Manager,dc=summitnjhome,dc=com" "(objectclass=sudoRole)" -W
ldap_start_tls: Connect error (-11)
	additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Enter LDAP Password: 
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
	additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```

If I provide some more information with the -d -44 flags this is what I see:


```
[root@VIRCENT03:~]#ldapsearch -h LBSD2.summitnjhome.com -b "dc=summitnjhome,dc=com" -d -44 -Z -D "cn=Manager,dc=summitnjhome,dc=com" "(objectclass=sudoRole)" -W
ber_dump: buf=0x8eb62e8 ptr=0x8eb62e8 end=0x8eb6307 len=31
  0000:  30 1d 02 01 01 77 18 80  16 31 2e 33 2e 36 2e 31   0....w...1.3.6.1  
  0010:  2e 34 2e 31 2e 31 34 36  36 2e 32 30 30 33 37      .4.1.1466.20037   
ber_dump: buf=0x8eb62e8 ptr=0x8eb62ed end=0x8eb6307 len=26
  0000:  77 18 80 16 31 2e 33 2e  36 2e 31 2e 34 2e 31 2e   w...1.3.6.1.4.1.  
  0010:  31 34 36 36 2e 32 30 30  33 37                     1466.20037        
ber_dump: buf=0x8eb7678 ptr=0x8eb7678 end=0x8eb7684 len=12
  0000:  02 01 01 78 07 0a 01 00  04 00 04 00               ...x........      
ber_dump: buf=0x8eb7678 ptr=0x8eb767b end=0x8eb7684 len=9
  0000:  78 07 0a 01 00 04 00 04  00                        x........         
request done: ld 0x8ead530 msgid 1
ber_dump: buf=0x8eb7678 ptr=0x8eb767b end=0x8eb7684 len=9
  0000:  78 07 0a 01 00 04 00 04  00                        x........         
ber_dump: buf=0x8eb7678 ptr=0x8eb767b end=0x8eb7684 len=9
  0000:  78 07 0a 01 00 04 00 04  00                        x........         
ber_dump: buf=0x8eb7678 ptr=0x8eb7684 end=0x8eb7684 len=0

TLS certificate verification: Error, unable to get local issuer certificate
TLS: can't connect.
ldap_start_tls: Connect error (-11)
	additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Enter LDAP Password: 
ldap_build_search_req ATTRS:
    supportedSASLMechanisms
ber_dump: buf=0x8f1e6a0 ptr=0x8f1e6a0 end=0x8f1e6e0 len=64
  0000:  30 3e 02 01 02 63 39 04  00 0a 01 00 0a 01 00 02   0>...c9.........  
  0010:  01 00 02 01 00 01 01 00  87 0b 6f 62 6a 65 63 74   ..........object  
  0020:  63 6c 61 73 73 30 19 04  17 73 75 70 70 6f 72 74   class0...support  
  0030:  65 64 53 41 53 4c 4d 65  63 68 61 6e 69 73 6d 73   edSASLMechanisms  
ber_dump: buf=0x8f1e6a0 ptr=0x8f1e6a5 end=0x8f1e6e0 len=59
  0000:  63 39 04 00 0a 01 00 0a  01 00 02 01 00 02 01 00   c9..............  
  0010:  01 01 00 87 0b 6f 62 6a  65 63 74 63 6c 61 73 73   .....objectclass  
  0020:  30 19 04 17 73 75 70 70  6f 72 74 65 64 53 41 53   0...supportedSAS  
  0030:  4c 4d 65 63 68 61 6e 69  73 6d 73                  LMechanisms       
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
	additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```

I am including the output of a -d -1 as an attachment for those that are still curious because the output of that command is quite long. 

When I issue getent commands for passwd and group it hangs forever when it tries to access information from ldap:


```
[root@VIRCENT03:~]#getent passwd | grep ldapAccount

[root@VIRCENT03:~]#getent group | grep ldapAccount
```

However if I remove TLS from the equation with the -x flag everything starts working again:


```
[root@VIRCENT03:~]#ldapsearch -x -h LBSD2.summitnjhome.com -b "dc=summitnjhome,dc=com" -D "cn=Manager,dc=summitnjhome,dc=com" -w localG30rg3T0wn "(objectclass=sudoRole)"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=sudoRole)
# requesting: ALL
#

# defaults, sudoers, Services, summitnjhome.com
dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here

# %wheel, sudoers, Services, summitnjhome.com
dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate
sudoUser: %wheel
sudoUser: bluethundr

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2
```

That's all I have for now. Sincere thanks to all those who have provided input. I'll keep pounding away at this and hopefully figure this out today.

Best regards!!!


----------



## bluethundr (Nov 28, 2010)

*revised ldap.conf*

I have also I have revised my /etc/ldap.conf on the client to read:


```
uri ldaps://LBSD2.summitnjhome.com/
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password crypt
```

I have also tried using


```
uri ldap://LBSD2.summitnjhome.com/
```

and 


```
host LBSD2.summitnjhome.com
```

with the same results as before. This was done so that the client will try to find a host with the same name as the one in the CN entry of the cacert. thanks again.


----------

