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?
-
2See also [What is an SSL certificate intended to prove, and how does it do it?](http://security.stackexchange.com/questions/6737/what-is-an-ssl-certificate-intended-to-prove-and-how-does-it-do-it). – curiousguy Jul 25 '12 at 19:39
-
1So 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
5 Answers
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).
![](../../users/profiles/2435.webp)
- 10,765
- 1
- 39
- 59
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.
![](../../users/profiles/11310.webp)
- 293
- 3
- 8
-
1It'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
-
-
I'm just saying it's not a [cache](http://en.wikipedia.org/wiki/Cache_%28computing%29). – Bruno Jul 25 '12 at 19:17
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.
-
1Just 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
-
Sorry if it's lame question but i'm kinda new. I'm assuming certificates only includes just public keys. So, isn't it possible for some attacker to intercept and mimic the server in the requested url and potentially return the same certificate that the real server would return (since they can also potentially access the 'public' key)? – zgulser Jul 28 '18 at 13:30
Here is my take on certificate vaildation. Assuming the web certicate has the correct name, the browser tries to find the Certificate Authority that signed the web server certificate to retrieve the signer's public key. The signing Certificate Authority may be part of a chain of CAs
With the public key the signature on the web site's certificate can be decrypted (this ensures that only the CA could have signed it unless their private key was compromised) to reveal a hash of the web server certificate. The browser also computes that hash of the web server certificate and if the two hashes match that proves that the Certificate Authority signed the certificate.
If the signer's public key cannot be found or the hashes don't match then the certificate is invalid.
The problem with this system is that Certificate Authorities are not completely reliable.
![](../../users/profiles/160821.webp)
- 103
- 2
![](../../users/profiles/141725.webp)
- 11
- 1
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 .
![](../../users/profiles/20852.webp)
- 101
- 3