Log in

Registration

Magazine
- Articles
- Books
- Howtos
- Nuts and Bolts
- Scripts
News
- BSD
- Hardware
- Linux
- OSS News
Support

Check SSL Services with OpenSSL s_client, Part II

Posted: June 29, 2011 / in: Howtos / No comments

When setting up SSL secured services, you have to take a close look at your service configuration.

This article contains details how to access and check SSL services that are utilizing self-signed SSL certificates or certificates issued by custom Certificate Authorities (CA).

Part I of this article series contains some common hints how to utilize openssl when configuring and checking services that are running certificates issued by well-known CA’s.

Contents

1 The OpenSSL Toolkit
2 Custom Certificates

The OpenSSL Toolkit

The OpenSSL Project provides a number of powerful tools related to security, encryption and a variaty of network protocols. This article will give you some hints how to utilize the client implementation s_client that is part of the binary openssl to check details of SSL secured network services.

OpenSSL s_client is a generic SSL/TLS client which can establish a transparent connection to a remote server speaking SSL/TLS. It’s intended for testing purposes only and provides only rudimentary interface functionality but internally uses mostly all functionality of the OpenSSL ssl library.

Custom Certificates

You might ask yourself, why to utilize self-signed certificates or certificates issued by custom CA’s. The answer is quite simple: Custom CA’s and self-signed certificates provide the same level of sevurity as the ones provided by the major CA’s. If you are running servers for testing purposes or you are serving a small audiance, you are not required to pay annual fees for CA services.

If you are interested in creating your own certificates, please take a look at our guide How to Create Self-Signed SSL Certificates with OpenSSL.

Setup Services

If you are interested in setting up your own SSL services or you just want to play around with example services, then you might setup a custom server (HTTPs, SMTPS, LDAPS, …). So, the next step would be to setup your SSL service by utilizing your freshly created certificate.

If you do need some assistance please check your Getting started Guide. At the bottom of the page this guide contains some hints how to configure some well-known open source products.

Error Messages

When trying to connect to remote SSL services your client applications have to trust the server certificate or the issuing CA certificate. If you do not provide additional information regarding (untrusted) SSL services, you will receive the following error messages.

unable to get local issuer certificate
certificate not trusted
unable to verify the first certificate

When utilizing a self-signed certificate there is no separate CA available. Client applications are required to trust the self-signed certificate that is utilized to run SSLsecured service.

Example Outputs

The following examples illustrate what will happen when SSL services are not trusted (your client application does not trust the remote service).

Within the next command line session we are trying to connect a SSL secured HTTP service whithout knowing the CA, that did issue the server certificate.

# connect to a HTTPS service - the issuing CA is unknown
$ openssl s_client -host messagegw-iat.noncd.db.de -port 443 -quiet -status
depth=0 CN = messagegw-iat.noncd.db.de, OU = Dienste, O = DB Systel GmbH, O = Deutsche Bahn, C = DE
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = messagegw-iat.noncd.db.de, OU = Dienste, O = DB Systel GmbH, O = Deutsche Bahn, C = DE
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = messagegw-iat.noncd.db.de, OU = Dienste, O = DB Systel GmbH, O = Deutsche Bahn, C = DE
verify error:num=21:unable to verify the first certificate
verify return:1

All security checks regarding the remote service did fail!

And another example:

# connect to a service with a self-signed vertificate
$ openssl s_client -host wiki.cacert.org -port 443 -quiet -status
depth=0 C = AU, ST = NSW, L = Sydney, O = CAcert Inc., CN = wiki.cacert.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = AU, ST = NSW, L = Sydney, O = CAcert Inc., CN = wiki.cacert.org
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = AU, ST = NSW, L = Sydney, O = CAcert Inc., CN = wiki.cacert.org
verify error:num=21:unable to verify the first certificate
verify return:1

Solve Problems

Solving the previous problems is quite simple. You just have to provide additional details regarding the remote SSL service.

In case of custom CA’s you have to store the CA certificate to file in PEM format. If you are utilizing a chain of CA servers just add all certificates of your CA chain sequence to a file in PEM format. In case of a self-signed server certificate handle this certificate as if it would be a custom CA certificate.

The following example illustrates how contents of a file in PEM format looks like. (The certificate is associated with www.cacert.org)

Now, that we have stored all related custom certificates to a file, we are ready to connect to the SSL service.

The next example contains outputs of the tool OpenSSL s_client while connecting to https://www.openca.org.

# connect to www.openca.org by providing the CA certificate
$ openssl s_client -host www.cacert.org -port 443 -CAfile www.cacert.org.pem 
CONNECTED(00000003)
depth=1 /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
verify return:1
depth=0 /C=AU/ST=NSW/L=Sydney/O=CAcert Inc./CN=www.cacert.org/emailAddress=support@cacert.org
verify return:1
---
Certificate chain
 0 s:/C=AU/ST=NSW/L=Sydney/O=CAcert Inc./CN=www.cacert.org/emailAddress=support@cacert.org
   i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFVzCCAz+gAwIBAgIDCKU1MA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
dEBjYWNlcnQub3JnMB4XDTEwMDUxNDE0NTk0OFoXDTEyMDUxMzE0NTk0OFowfjEL
MAkGA1UEBhMCQVUxDDAKBgNVBAgTA05TVzEPMA0GA1UEBxMGU3lkbmV5MRQwEgYD
VQQKEwtDQWNlcnQgSW5jLjEXMBUGA1UEAxMOd3d3LmNhY2VydC5vcmcxITAfBgkq
hkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAM3iqo3YIRO2BaAEEoZ/Ui8efBtl44PlQO71ubOvhc7lMU/W
SC/Vuw36z6O8WwvX2Lgx2gwYwJ94JvyHCAmNNQc0ohHHk7jNOeOieJKBX3kwCPnQ
SPQJpIZwR6gcpDsblEHADjq0Qugjdn5RTAg1v65xd8Y4yoalkETgtrncTZ1fkhpg
AVEYcx38JeLL3IHoDgTQH+M29XyIN2NJEnClkdoGftZlPCKEvd36T/kl6vrEm0Vy
ZV9orUAKG116J+Iwn+qFSgiz40gtDrpz9raEyixM72DqfY/4Gmgs1LrN19LEPu7u
IGvs/V8FqZ5twpfdctZq0iaq9fIGvWa1q9quvC0CAwEAAaOB4jCB3zAMBgNVHRMB
Af8EAjAAMDQGA1UdJQQtMCsGCCsGAQUFBwMCBggrBgEFBQcDAQYJYIZIAYb4QgQB
BgorBgEEAYI3CgMDMAsGA1UdDwQEAwIFoDAzBggrBgEFBQcBAQQnMCUwIwYIKwYB
BQUHMAGGF2h0dHA6Ly9vY3NwLmNhY2VydC5vcmcvMFcGA1UdEQRQME6CDCouY2Fj
ZXJ0Lm9yZ4IKY2FjZXJ0Lm9yZ4IMKi5jYWNlcnQubmV0ggpjYWNlcnQubmV0ggwq
LmNhY2VydC5jb22CCmNhY2VydC5jb20wDQYJKoZIhvcNAQEFBQADggIBAErVgsd2
7hZsBSMG+BbCHN9PUbJYAg7JMNYiIaPIsZGFUbuYGyqlLye5muLtMxTHzBfXM25+
ECwYy9jLpkzW7qz1dC2Glx4h6Gh6+//Klwa7rJ7M9EFuhMogY23YbCJMC2m1gGtW
Wer3kgQBbRI3LxiIf7HYbIdWGEJ2d1R0QjKPgQLn3gh3b9A35nptBQu/Zk3M/JzO
WV4WWG8TomBfLvYuG+tntZCrRCvnFZqN/+68qK74VVFR/wpbdnu+AEX7j44xhnGl
Wvye0S3zKQHnf0L01nMA4HXj1Z8+TyMMUNENF3/Of4SdDUnyFYjmUQAhZ49PHw1A
prPKZ7fijE+twQlHTPniDndgtWRU/m4IQadost2tgpZPZHiwNWiSeEgMMwwthIpa
WvLJFmUipxyxkqVKmb6r8geqAiN9ScvPkKX4x157FgxFd5nQ4ZnTjZ8Zg0vQDHaF
rNpELfvyLHppUiwOGt5NJmoSKyeII5k+80eAL/2Tngi1vM2rCznebGYa3LC7UoIT
zjX4N3bAcuq3l9UaGeFSp5D8oGv29DNC7sMNRJXtlGcLtjXJgJzaBSb0bsh468ri
nU4UDmnslHE2LEOkaswkGpq+eaxH/Cp5eE/rh7m+vLxm1jcuUnqNiJ+MmLJXMbFr
G6GvDP69u3UJgK5X/P6+WgXFSGEDJWb8gxUO
-----END CERTIFICATE-----
subject=/C=AU/ST=NSW/L=Sydney/O=CAcert Inc./CN=www.cacert.org/emailAddress=support@cacert.org
issuer=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
---
No client certificate CA names sent
---
SSL handshake has read 2031 bytes and written 293 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 61012426A1361D53717AF53333F147878C23FF3D761C8D2D9BEE2F63D7B9EF28E208D5CBD21E459227F1301652297915
    Key-Arg   : None
    Compression: 1 (zlib compression)
    Start Time: 1309329462
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

The last line contains the verification code of ’0′. This indicates, that your SSL connection has been established successfully. Now, your client application is ready to exchange data with the remote service.

Releated articles:

Check SSL Services with OpenSSL s_client, Part I – overview and basics
Check SSL Services with OpenSSL s_client, Part III – client authentication
How to Create Self-Signed SSL Certificates with OpenSSL

Related resources:

Incoming search terms:

Magazine
- Articles
- Books
- Howtos
- Nuts and Bolts
- Scripts
News
- BSD
- Hardware
- Linux
- OSS News
Support

Meta