2

When a CA's SSL certificate is stored in a browser, a server which presents a certificate signed by this CA can be verified by the browser. My question is: How exactly is this verification done?

I know that the certificate presented by the server to the browser contains information such as the server's public key and identifying information of the server (such as server name, location, etc).

But for the browser to prove that this information is correct, it needs a second copy of the same information to compare with and determine if there is a match or not. I know that the server's name is part of the URL, so the browser can get the value in the URL and compare with the information in the certificate. But what about the other information in the certificate? How is it verified when there is no second copy to compare with?

Improve this question

3 Answers 3

Reset to default
5

Subject identification in SSL/TLS server certificate is DNS name(s) usually and/or IP address(es) rarely, which are matched against the requested URL. Neither of these determines location. EV certificates must contain some physical location information verified by the CA, and other certs may, which the browser cannot further check; some browsers display some EV info, which the user could check against his/her knowledge of the organization/person that should be running the website.

The validity period is compared to the current time. If a client device has a wrong clock, or none, it can be tricked by a server using an expired cert for a stolen or broken key.

BasicConstraints, KeyUsage and ExtendedKeyUsage extensions if present (and at least the first two should be) are checked to make sure the cert is suitable for the SSL/TLS protocol in general and for the negotiated key exchange. Policies if present could be checked against configuration (or user entry) what policies are required, acceptable, or prohibited, but I don't think anyone does.

The Issuer name, and AuthorityKeyIdentifier (AKI) extension if present, are used to obtain (select) the parent CA public key used to verify the cert, so if they are wrong, the signature cannot be and is not verified. This repeats up the chain and validity, BC, KU, EKU are also checked up the chain to make sure each cert is suitable to be an issuer (CA).

All certs (including chain) must also be checked for revocation. This is done using information outside the cert(s), namely a CRL signed by the CA, or an OCSP response signed by the CA or other trusted party. Nowadays OCSP responses are usually included in the SSL/TLS handshake by the server (called stapling); if not the browser can fetch them using the cert(s) CRL Distribution Point and/or Authority Information Access extensions. This can provide an indirect check; if you get valid (signed) data from CRLDP and/or AIA.ocsp it establishes those values are right, but if you have trouble communicating it doesn't necessarily mean they're wrong, and if you don't even try (because of stapling) then obviously you don't know at all.

The Public Key in the cert cannot be directly checked; the main point of PKI is for the relier (browser) to securely obtain the public key which it does not already have. The SSL/TLS handshake does confirm that the server has (and uses) the private key corresponding to the public key in the cert; the cryptographic mechanism for this varies depending on the key exchange negotiated.

Improve this answer
1
  • I would add that "good" certificate chaining engine also does additional certification path validation by checking constraints. This would include application, certificate policy and name constraints.
    – Crypt32
    Jul 17, 2016 at 8:34
0

Certificate authority is the one issuing SSL and other digital certificates. It is highly trusted entity who verifies the information provided by web server such as its domain name, public key, the company’s identity. If all the information provided, are legal then the CA will issue the respective SSL certificate duly signed using its private key. Moreover SSL certificate follows three types of validation process namely domain, organization and extended validation. Depending upon the validation, the CA may go extend to verify the information of the business in detail.

Browsers sometimes may include public keys of CAs, as they line up with trusted roots installed within, cryptographically.

Once the certificate is issued CA provides its information, in case someone tries to invalidate the certificate then the browsers will become alert. Certificate information is provided either via certificate revocation lists (CRLs) or via online certificate status protocol (OCSP).

Improve this answer
0

The browser examines each certificate in the chain that terminates with a self-signed Trusted Root Certificate of the Certification Authority. This would be in the local certificate store. It verifies that the signature is valid, that the current time is within the validity period of each certificate as well as checking the CRL published location (http or LDAP). The CRL path must be available to read from the machine or the validation process will fail. Hope that helps.

Improve this answer
1
  • So the CRL path is also hard-coded in the browser?
    – Minaj
    Jul 20, 2016 at 19:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .