Hows is ssl certificate verified and by a browser or server

Question

I've created a self-signed sertificate

$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.csr
$ openssl x509 -req -in request.csr -signkey key.pem -out cert.pem

and created an HTTPS server:

var server = https.createServer({
    key: fs.readFileSync(__dirname + "/key.pem"),
    cert: fs.readFileSync(__dirname + "/cert.pem")
}

Then I requested the page. The expected result is that a browser complained that a connection is not secure. My question how does a browser know that? Is it server job to verify the certificate and notify browser about that or it's a browser job?

Answer 1

SSL Certificates are verified by the client.

The server typically will verify the certificate is not broken or corrupt on start-up, but most servers don't actually validate the legitimacy of their certificate.

Why verify the certificate?

Verification of the server certificate is important because otherwise the client can't really know who it is communicating with. MITM (Man In the Middle) attacks can take place where a third party is intercepting both sides of the communication and they can provide their data to you instead of the data from the server which you thought you were receiving.

A little bit about certificate types

Most certificates are signed by CAs, there are also self-signed certificates, and pinned certificates. I advise using a certificate signed by a CA whenever possible. The Second best option (which generally can only be used within an organization) would using your own internal CA and then self-signing your server cert with your CA cert, this is known as a self-signed certificate and it won't be trusted automatically by any clients or browsers which receive it.

In the self-signed option you must import your CA public key into your CA key store for your server certificate to be trusted. Finally there is simply a pinned certificate, this is where you simply tell your browser to trust an otherwise untrusted certificate (do not do this).

Warning - You should avoid pinning certificates because they are almost impossible to replace during a compromise, and certificates should be schedule to expire within a reasonable period, and be regularly rotated. Pinning makes that very difficult if almost impossible in some situations.

Types of certificates

• CA Signed (Needed to operate a secure site on the WWW)
• Self Signed (Good for internal organization usage, internal company wikis for example)
• Pinned (Avoid)

What kind of verification happens?

So you have a certificate, first you configure your server to use that certificate.

Now when a client comes along and requests a secure connection to your site (as indicated by connecting to port 443 in in the case of HTTPS). Your server sends it's public (not private) certificate and begins a secure handshake. One such handshake is called a Diffie–Hellman key exchange. The handshake itself is beyond the scope of this question.

Before participating in the key exchange, the browser will first examine the certificate which the server provided. For it to be valid several checks must be successful.

There are some of the checks performed.

• Does this certificate contain the hostname which matches the hostname we connected to?

  • If NO, does the certificate include a wildcard CN (Common Name)?
    • If YES, does that CN have a valid "wildcard" that matches the host name we're connected to? YES/NO

• Does the certificate include a CRL (Certificate Revocation List)? If so, does that CRL indicate that this certificate is still valid? YES/NO

• Is this certificate signed by a known certificate authority (CA)? YES/NO

  • Only if NO, does this client (browser) have a public certificate (which matches the certificate offered by this server), which has been marked as Trusted? YES/NO *This is also known as a pinned certificate, as you are not relying on a CA to verify it's authenticity.

For the browser to trust the certificate, and by proxy the server. Then we must check each of the Yes boxes above

Other security stuff that makes the world safer

Now there are other things not "specific" to the certificate which are also verified.

For example, both the client and server must agree on the handshake method, the ciphers used, the hashing algorithm used, and other things.

The server may also pass special HTTPS security flags instructing the browser not to trust other certificates for this service for a period of time (this is known as certificate pinning). Certificate pinning like that used in "Strict Transport Security" (not to be confused with pinning a certificate as mentioned above) can help prevent MITM (man in the middle) attacks. This is one of the many extra security features that HTTPS Strict Transport Security offers.

Once all of the security checks have been certified the browser sends any request it had to the server and the server responds appropriately.

Answer 2

When you visit a secured website (with https), the server also sends a certificate signed by an authority to prove its identity (so that you know you're not getting man in the middled).

Then, your browser needs to know if the certificate is genuine or not, because the man in the middle could send a certificate too. Luckily for you, your browser has a list of authorities to trust. If the certificate's authority signature matches one of the trusted authorities, then everything is fine and no alert is raised.

But if no authorities matches, then the browser kindly asks you if we can trust this authority. In the case of a self-signed certificate, you can trust it (but not before verifying the fingerprint, because, again, a man in the middle could send a different certificate to trick you into believing they're the real deal).

If you trust it, then the browser imports it and adds it to the certificates to trust, never raising an alarm again (until your certificates expires or change (like in a man in the middle situation)).

Answer 3

Is it server job to verify the certificate and notify browser about that or it's a browser job?

The main role of the server certificate is to make sure that the client is communicating with the expected server. If the client (browser) would just trust the server that the certificate is valid some man in the middle attacker could simply claim to be the real server and claim that the certificate is valid. And after this the client would establish the encrypted connection to the attacker instead of the real server which means that the attacker gets access to the sensitive data. Therefore the servers certificate must always be properly checked by the client.

My question how does a browser know that?

In short: by checking that the certificate is trusted by checking the signature of the issuer and following the trust chain up to a locally trusted root certificate, also checking that the hostname of the URL matches the subject of the certificate and that the certificates are still valid, i.e. not expired and not revoked. For more details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.