19

Am I right in my conclusion that validation of a certificate by a client that wishes to communicate with a server that offers said certificate, is done completely local? As in, the client is supposed to have all information (eg. CA's public key, used to sign the servers certificate) already locally available?

The exceptions being, I think, comparing the ip address/dns information offered through the certificate with the real world servers address and domain name.

An answer in another question (SSL Certificate Trust Model) in fact explictely states "In fact that's the whole idea of certificates: to allow offline validation.". Is that true?

Community
  • 1
JdeHaan
  • 293
  • 2
  • 8
  • This is a duplicate of this question: http://security.stackexchange.com/q/119295/70830 – Z.T. Oct 30 '16 at 11:54
  • 3
    @Z.T.: I don't consider this as a duplicate. The question you refer to only asks for communication with the CA while this question does not restrict itself to a specific communication peer. – Steffen Ullrich Oct 30 '16 at 13:30

2 Answers2

23

It is almost true. :) But not entirely.

A certificate can be revoked in case of a compromise. The only way to discover if a certificate is revoked at any given time is basically contacting the CA that issued it. Any info signed in the certificate itself (fit for offline validation) will be valid for a revoked cert.

There are two protocols for checking revocation, CRL and OCSP. A CRL is just a list of revoked certificates published by the CA, and OCSP is kind of a web service, but the idea is the same, any client doing cert validation should have a look and check if the certificate happens to be revoked.

In fact, a fairly common flaw in cert validation implementations is that they don't check revocation.

Gabor Lengyel
  • 1,173
  • 7
  • 11
20

Most of the validation is done using locally available information. But in some cases access to the internet is needed and if this access is not possible the validation might fail or the validation will take very long (i.e. timeouts to get online resources):

  • To get up-to-date information about the revocation status of certificatemost clients will do an OCSP request (at least for EV certificates) unless the the OCSP response is already sent within the TLS handshake (OCSP stapling). Note that this will not be done for each request, i.e. the information will be cached for some time. Similar client might get online from time to time to update any CRL lists they use (but most don't use CRL any more by default).
  • The validation of the trust chain might fail because an intermediate certificate is missing. Some clients (chrome desktop browser?) try to work around such broken server setups and try to download the missing intermediate certificate from the internet.
  • The validation of the trust chain might fail because the root CA is unknown. Some OS (Windows) might in this case ask a trusted server online if they have this missing root CA and will then download the unknown root CA and automatically trust it for this and future connections. See Automatic CA root certificate updates on Windows .
  • Additionally there might be checks to detect certificates which are issued due to a compromise of a CA or due to bugs and which are used in man in the middle attacks. Such checks might be done against a certificate transparency server or against Convergence notaries.
Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • 4
    Good to know which CA I trust on a Windows workstation: those contained in my trust store plus any other (depending on Microsoft decision in real time). – kubanczyk Oct 30 '16 at 12:54