One-way and two-way SSL authentication

How One-Way SSL Works?
Below is the high level description of the steps involved in establishment of connection and transfer of data between a client and server in case of one-way SSL:

1. Client requests for some protected data from the server on HTTPS protocol. This initiates SSL/TLS handshake process.
2. Server returns its public certificate to the client along with server hello message.
3. Client validates/verifies the received certificate. Client verifies the certificate through certification authority (CA) for CA signed certificates.
4. SSL/TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server’s public key.
5. After agreeing on this secret key, client and server communicate further for actual data transfer by encrypting/decrypting data using this key.

How Two Way SSL Works?

In Two-Way SSL authentication, the client and server need to authenticate and validate each others identities. The authentication message exchange between client and server is called an SSL handshake, and it includes the following steps:

• A client requests access to a protected resource.
• The server presents its certificate to the client.
• The client verifies the server's certificate.
• If successful, the client sends its certificate to the server.
• The server verifies the client’s credentials.
• If successful, the server grants access to the protected resource requested by the client.

The above steps are elaborated below in more technical terms and how the communication is established in a practical scenario.

1. Client Hello from client to server
    a. Client version (List of all SSL/TLS protocols client supports)
    b. Client random (A 32 byte random number to be used for generating encryption key)
    c. Session ID (blank if a new session)
    d. Compression method (Compression method to be used if compression is needed for SSL packets)
    e. Cipher suites (List of all cipher suites supported by client. Preferred one is first in the list)
    
2. Server Hello from server to client
    a. Server version (List of all SSL/TLS protocols server selected from client's provided list)
    b. Server random (A 32 byte random number to be used for generating encryption key)
    c. Session ID (Client provided session ID or a new ID in case of a new session)
    d. Compression method (Selected compression method to be used from the list provided by the client)
    e. Cipher suites (Selected cipher suite from the client's provided list)
    
3. Server Certificate from the server to client
    Server sends its certificate to the client containing public key of the server. This certificate
    acts as an identity of the server. Clients validate this certificate to ensure that it is not
    expired, it is issued by a trusted CA, it's digital signature is valid.
    
4. Certificate Request from server to client
    From mutual (2 Way) authentication, server sends a certificate request to the client
    
5. Server Hello Done from Server to Client
    Server confirms to the client that the server Hello message is finished.
    
6. Client Certificate from Client to Server
    TO enable SSL/TLS communication with two-way ssl, client sends it signed certificate to the server
    
7. Client Key Exchange from Client to server
    Client creates a pre-master secret and sends it to the server by encrypting it with server's public key.
    After decrypting pre-master key successfully, client and server will generate master secret using client
    random and server random communicated earlier. This master secret will be used to create session key for
    encrypting /decrypting data fro the entire session.
    
8. Client change cipher spec from client to server
    At this point, the client is ready to switch to a secure, encrypted communication. The change cipher spec
    protocol is used to change the encryption. Any data sent by the client from now on will be encrypted using
    the shared symmetric key.
    
9. Client handshake finished from Client to server
    At this step, handshake is completed from the client side and this becomes the first encrypted message for
    the created session.
    
10. Server change cipher spec from server to client
    The server is also ready to switch to an encrypted communication. Any data sent by the server from now on
    will be encrypted using the symmetric shared key.
    
11. Server handshake finished.
    The server completes the handshake by sending this message encrypted with the shared secret key.

The . pfx file, which is in a PKCS#12 format, contains the SSL certificate (public keys) and the corresponding private keys. When setting up two-way ssl communication, if the requirement is to share .pfx key with the other party, they will get the private key also.

What does SSL certificate include?
An SSL certificate contains information of the owner/organization, its location public key, validity dates, etc. It is mandatory that a valid certificate authority (CA) has validated the certificate.

Does SSL certificate contain private key?
All TLS certificates require a private key to work. The private key is a separate file that’s used in the encryption/decryption of data sent between your server and the connecting clients.

The certificate authority (CA) providing your certificate (such as DigiCert) does not create or have your private key. A private key is created by us — the certificate owner — when we request SSL certificate with a Certificate Signing Request (CSR). It should be saved safely on the server where it is generated. Private key should not be sent to anyone, as that can compromise the security of your certificate.

If you are yet to install your certificate, then the most likely location of your private key is on the computer or server where you generated the key pair and CSR. When you generated the key pair, you saved two files: one that contains the public key and one that contains the private key.

On Windows servers, the OS manages your certificate files for you in a hidden folder, but you can retrieve the private key by exporting a “.pfx” file that contains the certificate(s) and private key. Open Microsoft Management Console (MMC). In the Console Root expand Certificates (Local Computer). Your server certificate will be located in the Personal or Web Server sub-folder. Locate and right-click the certificate, identified by the Common Name, select Export and follow the guided wizard.