Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Jul 25 '12 at 19:11

This question came from our site for professional and enthusiast programmers.

So it's not possible to intercept communication between the browser and a CA to fake a valid certificate as the certificate is likely already in the browser's cache ? – André Thériault Jul 25 '12 at 19:30

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.

So it's not possible to intercept communication between the browser and a CA to fake a valid certificate as the certificate is likely already in the browser's cache ?

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).

share|improve this answer

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 Issued to field, the Issued By field contains a Trusted Certificate Authority, expiration date looks good in the Valid From field, etc.

Additionally each certificate contains URLs that point to Certificate Revocation Lists (CRL Distribution Points), the client will attempt to download the list from such URL and ensure the certificate at hand has not been revoked.

To answer your question

Are they requesting data from SSL Certification web site like GeoTrust to validate the certificate received from the web server ?

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.

share|improve this answer
Just a few details: it's not necessarily the "highest" cert (i.e. root), but any CA cert part of your trust anchors. It's not the URL that matches, but the host name and what it must match is the Subject Alt. Name, or Subject DN when there's no SAN (that's different from trusting the cert itself anyway). The Issuer DN doesn't have to be the Subject DN of one of the CAs you trust directly, there can be intermediates. – Bruno Jul 25 '12 at 19:19

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.

share|improve this answer
It's not really a cache. It's a pre-defined repository of certificates that doesn't update itself automatically when encountering new certificates. In addition, servers don't have to send the full chain (in fact, the root CA cert is never required, since it should be part of the trust anchors anyway). – Bruno Jul 25 '12 at 19:08
Some programs misbehave if it is not present. – Wug Jul 25 '12 at 19:15
I'm just saying it's not a cache. – Bruno Jul 25 '12 at 19:17

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: .

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.