Testing an SSL service or TLS enabled service isn't all that easy using common techniques: using telnet or netcat you can only see that something answers on a given port. However, you'll get no useful information regarding the certificates in involved that way. OpenSSL and GNUTLS provide tools to help with that.
Testing SSL servers (in this example, https)
OpenSSL has the function s_client which can be used to get the information we want:
$ openssl s_client -connect www.ccc.de:443
CONNECTED(00000003)
depth=0 C = DE, ST = Hamburg, L = Hamburg, O = Chaos Computer Club...
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Hamburg, L = Hamburg, O = Chaos Computer Club...
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = DE, ST = Hamburg, L = Hamburg, O = Chaos Computer Club...
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=DE/ST=Hamburg/L=Hamburg/O=Chaos Computer Club e.V./CN=...
i:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
---
Server certificate
-----BEGIN CERTIFICATE-----
< Certificate here >
-----END CERTIFICATE-----
subject=/C=DE/ST=Hamburg/L=Hamburg/O=Chaos Computer Club ...
issuer=/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
---
No client certificate CA names sent
---
SSL handshake has read 1839 bytes and written 409 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: AF312E52F8D5F2B6441436F0D666588FD4C5...
Session-ID-ctx:
Master-Key: FF103B4A274E8B90E905AA07C6DB45AB3F32...
Key-Arg : None
PSK identity: None
PSK identity hint: None
TLS session ticket:
< hexdump here >
Start Time: 1282561578
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
Now you're on a secured connection and can use HTTP as you're used to (i.e. GET, POST etc). Not that the output above also allows you to find out what certificates are in use, who issued them and when they will expire.
Testing TLS enabled services (here: SMTP+TLS)
While TLS can operate in the same way that SSL does (encryption starting with the very first bit transmitted), it also has a mode in which you first establish the connection and then secure it later on. In the case of SMTP, this happens after issuing EHLO bys sending "STARTTLS" (if the server advertises it in response to EHLO).
$ gnutls-cli -s mx.example.com -p 25 Resolving 'mx.example.com'... Connecting to '192.168.0.1:25'... - Simple Client Mode: 220 mx.example.com ESMTP Exim 4.69 Mon, 04 Aug 2008 11:59:34 +0200 EHLO client.example.com 250-mx.example.com 250-SIZE 52428800 250-PIPELINING 250-AUTH CRAM-MD5 250-STARTTLS 250 HELP STARTTLS 220 TLS go ahead
At this point, the server expects the client (us) to initiate the TLS handshake. Since the GNUTLS client itself doesn't know this (and can't, because every protocol is different), we have to tell it to go into TLS mode. This is accomplished by sending it the ALARM signal (SIGALRM, usually #14). This can be done easily from another terminal:
$ pkill -ALRM gnutls-cli
As a result, the client does all the crypto stuff required and tells us which certificates it has encountered along the way:
*** Starting TLS handshake - Ephemeral Diffie-Hellman parameters - Using prime: 776 bits - Secret key: 760 bits - Peer's public key: 768 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'mx.example.com'. # valid since: Fri Jan 18 09:22:21 CET 2008 # expires at: Wed Jul 16 10:22:21 CEST 2008 # fingerprint: A6:8E:2F:1B:03:36:A8:BA:CF:9F:37:0E:53:7E:D0:4A # Subject's DN: CN=mx.example.com # Issuer's DN: O=Root CA,OU=http://www.cacert.org,CN=CA ... - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL
As with SSL, you now have a secured connection that you can use like any other SMTP connection (or exit):
ETRN 250 OK QUIT 221 'mx.example.com' closing connection - Peer has closed the GNUTLS connection $
Security note
While both clients check the certificate for internal validity and expiry date, they can't do anything in the way of certificate chain validation unless you provide appropriate root certificates). This means that while they tell you the contents of the certificate, they usually can't tell you whether the certificate's signature is trusted in any sense. Hence, they tell you that they're not trusted. SSL does this with the line verify error:num=27:certificate not trusted, TLS does so with Peer's certificate is NOT trusted.