1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

using a godaddy SSL cert with openLDAP

Discussion in 'Web and Network Services' started by bluethundr, Nov 25, 2010.

  1. bluethundr

    bluethundr New Member

    Messages:
    62
    Thanks Received:
    0
    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!
     
  2. bluethundr

    bluethundr New Member

    Messages:
    62
    Thanks Received:
    0
    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:

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

    Attached Files:

  3. bluethundr

    bluethundr New Member

    Messages:
    62
    Thanks Received:
    0
    revised ldap.conf

    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.