Certificate & Hash checking?

Question

I'm asking this question in order for be 100% sure.

To validate the certificate to ensure it contains the information digitally signed by the certificate authority, the web browser verifies the digital signature. Because the digital signature is an encrypted hash value that was computed based on the contents of the certificate, the web browser needs to compare hash values. The web browser computes a hash value based on the contents of the certificate it received. It then decrypts the digital signature to determine the hash value that the certificate authority computed. If the two hash values match, the web browser is assured that the certificate contains the information that the certificate authority verified and digitally signed.

questions :

The web browser computes a hash value based on the contents of the certificate it received

The browser knows in which digest algorithm the certificate was used inside , so he uses it also to calculate a hash - based on the certificate content.

It then decrypts the digital signature to determine the hash value that the certificate authority computed

The browser knows which CA created the certificate , so he takes the public key from the appropriate computer store location and apply it on the encrypted hash value . the result is the decrypted hash value.

It then see if both the same.

Am I right ?

Bruno Bruno · Accepted Answer · 2012-09-28T19:21:10

(You may be interested in this question on Security.SE.)

This is the structure of an X.509 certificate:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  EXPLICIT Extensions OPTIONAL
                          -- If present, version MUST be v3
     }

When presented with the certificate, the browser gets the signature algorithm from the certificate itself. Typically, this is something like RSAwithSHA1.

In this case, it can indeed recalculate the SHA-1 digest of the TBSCertificate (the actual content of the certificate).

In addition, from the TBSCertificate, it can find the issuer name: this is what's used to find a trust anchor from the known CA certificates (the issuer name must match the subject of the CA certificate). When it has found the CA certificate with the right name in the list it already trusts, it can get the public RSA key from that CA certificate.

Having both the SHA-1 digest and the RSA public key, it can verify that the signatureValue matches.

the digital signature is an encrypted hash value

That's not strictly true, although it's commonly said. Digital signatures are digital signatures, not encryption.

The problem is that RSA uses the same maths to encrypt and sign: encryption with the public key and signature with the private key. Often, one is confused with the other (even in the OpenSSL API). It doesn't make sense to "encrypt" with a private key, since "encrypting" implies hiding (and you're not hiding anything if you're giving the public key away so the it can "decrypt" the signature).

This subtly about hash and encryption with digital signatures wouldn't work with some other algorithms such as DSA, which are for signatures only.

This is why a number of digital signature APIs combine the hash and key usage into a single "sign" or "verify" operation. This is what the Java Signature API does, for example: you tell it to use RSAwithSHA1 or DSAwithSHA1, give it the key and the message, and tell it to sign or verify, you don't have to do the digest or "encryption" manually.

For the purpose of certificate verification: the browser gets the issuer from the cert and find the corresponding public key (from trusted CA certs), it also gets the signature algorithm from the cert, and then verifies the signature with that public key and the TBSCertificate content, according to what the signature algorithm dictates.

Certificate & Hash checking?

1 Answers