using a godaddy SSL cert with openLDAP

bluethundr · #1 November 25th, 2010, 17:37

Hello FreeBSD,

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

Code:

[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:

Code:

[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:

Code:

-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:

Code:

[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

Code:

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 · #2 November 28th, 2010, 20:10

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:

Code:

[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:

Code:

[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:

Code:

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.

Code:

## 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:

Code:

-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;

Code:

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:

Code:

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:

Code:

[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:

Code:

[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:

Code:

[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:

Code:

[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:

Code:

[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 · #3 November 28th, 2010, 20:53

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

Code:

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

I have also tried using

Code:

uri ldap://LBSD2.summitnjhome.com/

and

Code:

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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Solved] Issue with openldap	rasperin	Installation and Maintenance of FreeBSD Ports or Packages	1	February 18th, 2010 23:52
[Solved] Sending E-Mail using sendmail & GoDaddy 's DNS settings (SPF, PTR...)	aurora72	Web & Network Services	8	December 21st, 2009 22:28
OpenLdap ACL	imran	Web & Network Services	1	October 24th, 2009 14:59
OpenLDAP	imran	Installation and Maintenance of FreeBSD Ports or Packages	3	September 26th, 2009 20:55