You are on page 1of 4

How To Verify SSL Certificate From A Shell Prompt The s_client and s_server options provide a way to launch

SSL-enabled command-line clients and servers If youre trying to configure a service that includes a TLS/SSL handshake and you want to know if the problem youre experiencing is related to the application, firewall, certificate trust, misconfiguration, etc. heres a way to eliminate TLS/SSL from your list of usual suspects. Im 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 im having. The only thing the app tells me is Unable to read schema First ill verify that my certificate is trusted. Lets see who issued my certificate. # openssl x509 -noout -in pearlin.crt -issuer issuer= /DC=com/DC=DOMAIN/CN=rootserver Now I know which CA this came from, ill 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 I can try to use it to connect. But lets say I try to use a self-signed certificate or another cert thats not trusted If its a trust issue, perhaps the certificate is valid, but it just cant find the CA or intermediate certificate. $ openssl s_client -connect CONNECTED(00000003) depth=0 / verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 / verify error:num=27:certificate not trusted verify return:1 depth=0 / verify error:num=21:unable to verify the first certificate verify return:1 Certificate chain 0 s:/ i:/DC=com/DC=domain/

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/ verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=State/L=City/O=organization/ 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/ Daddy CA/serial=007 verify return:1 depth=0 / Control Validated verify return:1 Certificate chain 0 s:/ Control Validated i:/C=US/ST=Az/ Daddy CA/serial=007

1 s:/C=US/ST=Az/ 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=/ Control Validated issuer=/C=US/ST=Az/ Daddy CA/serial=007 Acceptable client certificate CA names / 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)

Yes, you can check a certificate with openssl (available for windows and *nix).
openssl x509 -in certificate.crt -text -noout