HOWTO test certificates for tls

The following documentation can be used to generate your own chain with a CA:

generate certificates

The certificates will be tested with OpenSsl libraries :

s_server
s_client

Test certificates with a client-to-server TLS handshake¶

Server side¶

The server needs :

The server private key
The server certificate
The CA certificates chain

Run :

openssl s_server -accept 2121 -Verify 3 -key server.key.pem -cert server.cert.pem -CAfile ca.pem

Clues about options :

accept : the optional TCP host and port to listen on for connections
verify, Verify : the verify depth to use. This specifies the maximum length of the client certificate chain and makes the server request a certificate from the client. With the -verify option a certificate is requested but the client does not have to send one, with the -Verify option the client must supply a certificate or an error occurs
key : the server private key to use. If not specified then the certificate file will be used
cert : the server certificate to use
CAfile : a file containing trusted certificates to use during client authentication and to use when attempting to build the server certificate chain. The list is also used in the list of acceptable client CAs passed to the client when a certificate is requested

Client side¶

The client needs :

The client private key
The client certificate
The CA certificates chain

Run :

openssl s_client -connect localhost:2121 -Verify 3 -key client.key.pem -cert client.cert.pem -CAfile ca.pem

Clues about options :

connect : this specifies the host and optional port to connect to. It is possible to select the host and port using the optional target positional argument instead. If neither this nor the target positional argument are specified then an attempt is made to connect to the local host on port 4433
verify, Verify : the verify depth to use. This specifies the maximum length of the server certificate chain and turns on server certificate verification. Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure
key : the client private key to use. If not specified then the certificate file will be used
cert : the client certificate to use, if one is requested by the server. The default is not to use a certificate
CAfile : a file containing trusted certificates to use during server authentication and to use when attempting to build the client certificate chain.

In some cases, the server doesn't need to authenticate to the client. If so, you can remove the option -CAfileof the server command and the option -Verify of the client command. The client continues to authenticate to the server."

Explanation about TLS¶

Handshake¶

Certificates are used by two connecting entities to proceed to a TLS handshake to establish the secret keys with which they communicate.

The steps that enable the TLS client and server to communicate with each other are :

Agree on the version of the protocol to use
Select cryptographic algorithms
Authenticate each other by exchanging and validating digital certificates
Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem. SSL or TLS then uses the shared key for the symmetric encryption of messages, which is faster than asymmetric encryption

handshake_overview

For client authentication, the server uses the public key in the client certificate to decrypt the data the client sends during step 5 of the handshake. The exchange of finished messages that are encrypted with the secret key (steps 7 and 8 in the overview) confirms that authentication is complete.

If any of the authentication steps fail, the handshake fails and the session terminates.

How TLS provide authentication¶

Consider that CA X issues the certificate to the TLS client, and CA Y issues the certificate to the TLS server.
If the SSL or TLS server requires client authentication, the server verifies the client's identity by verifying the client's digital certificate with the public key for the CA that issued the personal certificate to the client, in this case CA X. For both server and client authentication. The certificates required are as follows, where the server needs :

The personal certificate issued to the server by CA Y
The server's private key
The CA certificate for CA X

and the client needs:

The personal certificate issued to the client by CA X
The client's private key
The CA certificate for CA Y

Both the SSL or TLS server and client might need other CA certificates to form a certificate chain to the root CA certificate. For more information about certificate chains, refer to the related information.

Recommendations about the chain of certificates¶

During a TLS handshake, you should provide the root certificate of the chain to the client side and only use a chain with a intermediate certificate for the server side.

Why ? Because :

The server's certificate, with its chain, is not for the server. The server has no use for its own certificate. Certificates are always for other people (here, the client). What is used by the server is its private key (that corresponds to the public key in its certificate). In particular, the server does not need to trust its own certificate or any CA which issued it.
In TLS, the server is supposed to send a chain; and the client is supposed to somehow use the server's public key for the handshake. The client is free to "know" that public key in any way that it wishes to, although of course it is expected that the client will obtain the server's public key from the certificate chain that the server just sent. Browsers will primarily try to use the chain sent by the server (by trying to link it below one of the roots already trusted by the browser); in case of failure, they will try to build other chains based on intermediate CA certificates that they already know or can download on-the-fly.