Sectigo Personal Authentification Pro

Sectigo PERSONAL AUTHENTICATION PRO

An SSL/TLS certificate is used to secure the data transmission between a user’s browser and the website’s server. When most people talk about these certificates, they’re referring to server certificates, which are used to authenticate servers to clients. However, what if you need to perform client authentication, meaning that you want to authenticate the client to the browser? This is where two way SSL certificates (or “2 way SSL”) come in handy.

Why would I need to use this other type of certificate? Because when both of these types are certificates are used, it facilitates mutual authentication between both parties.

There is one very important thing to know: Unlike a standard SSL certificate, a two way SSL certificate is actually known as a personal authentication certificate (PAC).

But before we jump into exploring the meaning of both of these SSL types, you first must be familiar with how the HTTPS connection is made. So, let’s have a quick review:

How SSL Authentication Works (A Brief Overview)

• The website owner buys an SSL certificate for their domain name(s) and sends an unsigned certificate with their public keys to the certificate authority (CA).
• The CA verifies the identity and domain ownership of the applicant by following a validation process. After successful validation, the CA issues an SSL certificate for the domain, ties the server’s public key to the certificate and signs it with its own intermediate root certificate.
• When a browser (client) tries to connect to a website, the SSL handshake process takes place.
• Once the SSL handshake process is over, the browser generates a session key and encrypts it using the public key attached in the server’s SSL/TLS certificate.
• The session key reaches to the server. The server decrypts it using the corresponding private key.
• Now, this session key is used for encrypting and decrypting all the data transferred between a server and the browser.

The reason we have highlighted the word “SSL handshake process” here is because in the one-way SSL and the 2 way SSL, only the type of certificate that’s used and the SSL handshake process itself differs. All the other steps remain the same.

Now that you know the basics, let’s proceed further to explore the meaning, working style, and usage of the one-way SSL and two way SSL authentication processes.

How One-Way SSL Authentication Works with a Traditional SSL/TLS Certificate

Let’s start with the SSL certificate you’re most familiar with. In all the communications, there are two endpoints involved, the browser and the website it’s connecting to (i.e., a client and server). In one-way SSL authentication, only the identity of one endpoint — the server — is verified. When you try to open a website, your browser authenticates the legitimacy of the website’s server by checking the site’s SSL certificate. One-way SSL certificates are also known as server authentication certificates.

Let’s understand how the SSL handshake process takes place in one-way SSL authentication:

1. When a user attempts to connect to a website on their web browser, the browser tries to establish an HTTPS connection to the website’s server. It sends the supported cipher suites to the server in the ClientHello process.
2. The server responds by sending its public certificate (i.e., the SSL/TLS certificate) to the browser.
3. The browser checks whether the certificate is legitimate (i.e., not expired or revoked), supporting the latest algorithms, properly configured, etc.
4. After that, the browser checks the validity of the CA’s signature from its pre-installed root store.
5. If everything seems fine, the SSL handshake process completes, and the browser generates the session key.

As you read above in the entire SSL handshake process, only the server’s SSL certificate is verified. Basically, this process enables the browser to ensure that it’s connecting to the right website’s server, and that all of the data is routed to the intended site only via a secure connection.