rootninja

The s_client and s_server options provide a way to launch SSL-enabled command-line clients and servers

If you’re trying to configure a service that includes a TLS/SSL handshake and you want to know if the problem you’re experiencing is related to the application, firewall, certificate trust, misconfiguration, etc. here’s a way to eliminate TLS/SSL from your list of usual suspects.

I’m trying to use an Active Directory Domain Controller to supply a list of objects for an application running on a Linux machine, and I want to make sure the TLS/SSL is working, is trusted, and has nothing to do with the problem i’m having. The only thing the app tells me is “Unable to read schema”

First i’ll verify that my certificate is trusted. Lets see who issued my certificate.

# openssl x509 -noout -in rootninja.crt -issuer

issuer= /DC=com/DC=DOMAIN/CN=rootserver

Now I know which CA this came from, i’ll make sure I use that CA instead of whatever default one it might look at

# openssl verify -CApath /etc/pki/tls/ -CAfile rootserver.pem

rootserver.crt: OK

So now I know this certificate is blessed by my client, I can try to use it to connect. But let’s say I try to use a self-signed certificate or another cert that’s not trusted…

If it’s a trust issue, perhaps the certificate is valid, but it just can’t find the CA or intermediate certificate.

$ openssl s_client -connect rootserver.rootninja.com:636

CONNECTED(00000003)
depth=0 /CN=domainCA.rootninja.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=domainCA.rootninja.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=domainCA.domain.com
   i:/DC=com/DC=domain/CN=dc1.domain.com
-----BEGIN CERTIFICATE-----
...

...
Verify return code: 21 (unable to verify the first certificate)
---

And using a self-signed certificate, you should see something like this.

CONNECTED(00000003)
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=State/L=City/O=organization/CN=ldap01.rootninja.com
verify return:1
...

...
No client certificate CA names sent
---
SSL handshake has read 983 bytes and written 331 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
...

...
    Verify return code: 18 (self signed certificate)
---

But, if everythings working correctly, your client should connect just fine. And it will look something like this, with a big fat Verify return code: 0 (ok) at the end.

CONNECTED(00000003)
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=1 /C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
verify return:1
depth=0 /CN=rootserver.rootninja.com/OU=Domain Control Validated
verify return:1
---
Certificate chain
 0 s:/CN=rootserver.rootninja.com/OU=Domain Control Validated
   i:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
 1 s:/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...

...
-----END CERTIFICATE-----
subject=/CN=rootserver.rootninja.com/OU=Domain Control Validated
issuer=/C=US/ST=Az/O=GoDaddy.com/OU=http://certs.godaddy.com/repository/CN=Go Daddy CA/serial=007
---
Acceptable client certificate CA names
/CN=rootserver.rootninja.com/OU=Domain Control Validated
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root CA
/CN=NT AUTHORITY
---
SSL handshake has read 4561 bytes and written 355 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 7407077777C77707177C7
    Session-ID-ctx:
    Master-Key: 7A97FE707C7078797B7437075E7F7267F5787E
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1234567890
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

http://www.openssl.org/

howto, security certificate, handshake, https, ldap, ldaps, openldap, openssl, self-signed certificate, ssl, s_client, tls

This doesn’t have to be complicated at all.  This was what I did on my ldap servers:

That’s it!  No messing with the CA.pl script or running multiple openssl commands for requests, signings, password stripping, and catting keys/crts together.  I tested my LDAP implementation like this and it worked like a charm.  Having a copy of both certificates located at /etc/openldap/cacerts/ on both machines worked for me.  When I set up clients, I put the certs in their cacerts directory and they work just fine with start tls.  If you’re doing this for an openldap implementation, you can make sure it’s working using “ldapsearch -x -ZZ” which requires your encryption to work.

http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg“>http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg” alt=”root|ninja” width=”80″ height=”15″ />

Linux cert, key, ldap, openldap, openssl, pki, self-signed certificate, ssl, tls