Hey list,
I was having a similar SSL/openLDAP problem to this last week. I had a chance to look at this again today and it still appears to not be working. I called godaddy and had the last cert cancelled and reissued as I had mis-typed the name of the CN on the last one.
I am trying to setup a Godaddy turbo SSL certificate with an openLDAP 2.4 server under FreeBSD 8.1. The clients are mainly a network of virtual CentOS 5.5 instances.
[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 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.summitnjhome.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:
-rw-r--r-- 1 root bluethundr 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:/tmp/Foswiki-1.1.2]#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:
ldapsearch -h ldap.example.com -d -1 -ZZ "dc=example,dc=com"
TLS certificate verification: depth: 0, err: 20, subject: /O=LBSD2.summitnjhome.com/OU=Domain Control Validated/CN=LBSD2.summitnjhome.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 wrote:
I have setup the certificate chain in my slapd.conf like so:
TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
I don't see where you say which directory these are stored in:
-rw-r--r-- 1 root bluethundr 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
[root@LCENT01:/tmp/Foswiki-1.1.2]#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')
It looks like the expected directory is not the one being used. Perhaps try use this invocation:
openssl s_client -connect ldap.example.com:389 -showcerts -CAfile /path/to/sf_issuing.crt
Best regards,
Hello CentOS:
Thanks for your input..
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 ldap.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 ldap -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 ldap -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 ldap -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!!!
On Thu, Nov 25, 2010 at 1:25 PM, cpolish@surewest.net wrote:
bluethundr wrote:
I have setup the certificate chain in my slapd.conf like so:
TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
I don't see where you say which directory these are stored in:
-rw-r--r-- 1 root bluethundr 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
[root@LCENT01:/tmp/Foswiki-1.1.2]#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')
It looks like the expected directory is not the one being used. Perhaps try use this invocation:
openssl s_client -connect ldap.example.com:389 -showcerts -CAfile /path/to/sf_issuing.crt
Best regards,
Charles Polisher
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
bluethundr -
cpolish＠surewest.net