HTTPS and certificates

Question

How does HTTPS work with certificate acceptance?

Answer 1

Very sipmly put with a little history :

Client : (connects to the server and issues it) "Hello! Here is my encryption data."

Server : (takes the client’s hand) "Hello. Here is my encryption data. Here is my certificate." (Handshake approval completed. Client verifies certificate)

Client : Great, here is my key! Therefore, from now on, everything is encrypted using this key. Ok

Server : OK! (SSL handshaking completed)

Client : Great, here is my HTTP data!

Certificates are used in SSL handshaking . The certificate that the server sends to the client is signed through a Certificate Authority (CA), for example VeriSign, and is server specific. There are various checks that occur in SSL handshakes. One of the important ones to be aware of is that the Common Name attribute of the certificate must match the hostname / DNS of the server.

The client has a copy of the CA public certificate (key) and can therefore use it (for example, using SHA1) to find out if the server certificate is still in order.

Answer 2

First of all, we need to distinguish between server-side and client-side certificates.

In most cases, only a server certificate is used. It is used to allow the client to verify the authenticity of the server to which the client is connected by verifying the server certificate (the verification procedure will be described later). This should prevent a man in the middle attack (MITM).

A client-side certificate is used when we need to restrict access to the server to only some users. To do this, the client authenticates with a certificate. Since the set of users is usually limited (by some criteria, it can be quite large in real life), the verification procedure is often slightly different from the verification procedure of the server certificate.

Next, about the verification itself.

When checking the server certificate on the client, the client performs the following steps:

• Find the issuer certificate (CA) and verify the signature of the server certificate using the issuer certificate (technical data missing).
• Check the validity of the certificate (from the moment when the certificate should be accepted).
• Check the use of the certificate (each certificate may be limited only by certain purposes).
• Verify that the certificate was issued for the domain name (or IP address) on which the server resides.
• Verify that the certificate has not been revoked (revoked) by the CA. This is done by checking certificate revocation lists (CRLs) and sending the request on the fly using the OCSP protocol.
• Because CRLs and OCSP responses are signed using certificates, their signatures are also verified as described above.
• The procedure is repeated for the CA certificate mentioned in step (1), and this continues until you receive a trusted CA root certificate (it is assumed that the client has a set of trusted root certificates).

When the server checks the client certificate, the above procedure is usually simplified, since the same system is the CA and access to which is checked by the server. In this case, the certificates can either be mapped directly to the list of allowed certificates, or most of the above steps may be unnecessary.