What steps should I take to validate a SSL Certificate manually as browsers do?

Question

How do browsers like Chrome check SSL Certificate?

IS there any online databases or websites that they use?

What steps are taken by browsers to validate a SSL certificate?

Am I able to do it manually without using browser?

Answer 1

How do browsers like Chrome check SSL Certificate?

The certificate and chain are sent by the server during the SSL handshake. The browser will create the trust chain based on the certificate issuer, provided chain certificates, and the local root certificates. It will check the expiration and purpose of the certificate and also check the subject alternative names (and maybe the subject too) to make sure that the certificate is actually issued for the domain in the URL. It might also do some checks for certificate revocation.

For details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? and How Do Browsers Handle Revoked SSL/TLS Certificates?.

Is there any online database or websites that they use?

Not really. The necessary trust store is local. They might check revocation though against some online resource. See Is Certificate validation done completely local?.

Am I able to do it manually without using a browser?

Sure, what the browser does could in theory be replicated manually. You can for example access the site and get the leaf and intermediate certificates with openssl s_client -showcerts .... You can then use openssl verify to verify the certificate chain, see also Verify a certificate chain using openssl verify. Then you need to look at the leaf certificate with openssl x509 -text ... to check purpose, expiration and the subject. Revocation is tricky but could be done with the help of openssl crl and openssl ocsp, although this does not really reflect what browsers do.

Answer 2

The official algorithm for validating any SSL/TLS certificate is defined by PKIX as modified by OCSP. For TLS nowadays the OCSP token is often transported by 'stapling' in the TLS handshake instead of by a separate connection, which requires several other RFCs, but that only affects transport, not the actual validation by the relier. For HTTPS specifically, the client must also check server identity aka 'hostname' as defined by rfc2818.

In practice, browsers may vary some. Chrome mostly uses a google-determined scheme to 'push' revocation data they select, but this has changed from time to time. Firefox, last I heard, used their own 'one-CRL' scheme. Also, although the standard and traditional practice was to check hostname against SAN if present and otherwise fall back to Subject.CN, Chrome since a few years ago requires SAN and never uses CN; you can find dozens of Qs on several stacks about "my selfsigned or otherwise DIY cert not from a real CA stopped working on Chrome".

If by 'do it manually' you really mean manually, that will be a lot of work. If you mean with tools other than a browser offline, somewhat easier; OpenSSL (if installed) can do most of this, although you need more options than shown in Steffen's link to get it right.

If you mean with tools other than a browser online, absolutely. The WWW has become extremely popular in recent decades, and there are zillions of programs and libraries for accessing it, nearly all of them including HTTPS (although two decades ago that was less common), which includes validating the certificate -- at least by default; many have options to disable, bypass, or override validation. There are standalone tools like curl and wget -- or openssl s_client can do the SSL/TLS and certificate part without doing HTTP on top. There are innumerable libraries and middlewares like ssl in python (or requests using it), tls in nodejs, (older) HttpsURLConnection and (newer) java.net.http in Java as well as third-parties like Apache HttpComponents; I'm sure there are counterparts for perl and dotnet although I'm not familiar with them. As well as powershell, which is fuzzy on the program/library distinction.