How are Chrome and Firefox validating SSL Certificates? Are they requesting data from an SSL certification website, like GeoTrust, to validate the certificate received from the web server?
migrated from stackoverflow.com Jul 25 '12 at 19:11
Note that Google Chrome stopped using CRL lists around February 7, 2012 to check if a certificate was valid. It seems that they build all the valid certificates into the browser and install a new set every time the browser is updated. See URL: https://threatpost.com/en_us/blogs/google-stop-using-online-crl-checks-chrome-020712 .
Browsers and/or operating systems tend to come with a pre-defined list of CA certificates used as trust anchors to check the certificates of servers they connect to. They're all customisable (except for EV certificates, for which the root certificates are hard-coded into the browser, although you can disable them... bug excepted).
Firefox uses its own list on all platforms.
Internet Explorer and Chrome use the operating system's certificate repository on Windows. The default is available via Microsoft's Root Certificate programme.
Apple also has its programme.
Trusting an a priori unknown server certificate is done by building a certification path between this certificate and one of the browser's trust anchors. This is done as defined in RFC 3280/RFC 5280.
In addition, certificate revocation can also be checked, either via CRL or via OCSP.
To re-iterate the point I made as a comment to Wug's answers: the trust anchors repository is not a cache. A cache is a dynamic placeholder aimed to keep what you've accessed recently at your disposal, based on the assumption you'll need them again soon. In contrast, your trusted certificate list must never be updated automatically on the basis of what you're currently browsing. (It could be updated by automatic security updates, but that's a different issue.)
The server certificate will be obtained every time a new SSL/TLS session is established, and the browser must verify it every time. It's not cached. (You could have some OCSP caching, but that's to improve performance and kept only for a short period of time. This is just for verifying the revocation status, at the time of access.)
Contacting the CA is just for certificate revocation. You don't otherwise contact a CA. CA certificates (your trusted anchors) are a given, a "leap of faith", bundled for you by your OS/browser (which you can choose explicitly, but it's fixed as far as a given connection is concerned). At best you could prevent the certificate revocation check to happen (which may cause your browser to make its validation fail, depending on its settings).
As Wug explained, the validation occurs from the server certificate to the highest certificate in the chain. The browser will look at the certificate properties and perform basic validation such as making sure the URL matches the
Additionally each certificate contains URLs that point to Certificate Revocation Lists (
To answer your question
Yes, the browser will perform basic validation and then contact the CA authority server (through CRL points) to make sure the certificate is still good.
The web server will send the entire certificate chain to the client upon request. The browser (or other validator) can then check the highest certificate in the chain with locally stored CA certificates.
Most operating systems keep a cache of authoritative certificates that browsers can access for such purposes, otherwise the browser will have its own set of them somewhere.
A certificate can be signed by another certificate, forming a "chain of trust" usually terminating at a self signed authoritative certificate provided by an entity such as GeoTrust, Verisign, Godaddy, etc.
This would be a better question for the security SE site.
Google chrome, specifically, I'm not 100% sure uses the OS cache, but you can add an authoritative certificate via Wrench -> Settings -> Show Advanced Settings -> HTTPS/SSL -> Manage Certificates -> Trusted Root Certificate Authorities and adding an authoritative CA certificate there.