I have been looking at the SSL Certificate Trust Model, and there is something that does not make sense. If I am correct, the trust model makes it that if there is a chain of certificates with a trusted root certificate at the top of the chain, all certificates in this chain will be trusted. This does not make sense because then I could create a valid certificate for google.com with my own key pair. I would do this by taking the certificate chain of google.com, lets say Verisign, then google.com. I would leave the root certificate as it is, but modify the key pair in the google.com certificate. This certificate chain would be trusted because the root certificate is trusted, therefore all other certificates are trusted. This would allow you to create a man in the middle attack.

2 Answers 2


SSL certificates have an extension field that defines what a certificate is allowed to be used for.

When you buy a certificate from VeriSign with your certificate signing request, it typically will not include the extension permission for signing downstream certificates with your certificate; especially for any domain you don't have authority for.

Take google.com for instance (root to leaf node):

  1. Equifax Secure CA - Root CA (hence implicit downstream signing authority)
  2. GeoTrust Global CA - Has Certificate Signer property
  3. Google Internet Authority G2 - Has Certificate Signer property but can only sign leaf nodes
  4. *.google.com - Wildcard domain certificate with no authority to sign other certificates.

The browser checks validity from the root to the leaf. Any authority claimed by a leaf or intermediate certificate is assumed to have been authorised by the certificate that signed it; eventually culminating in the trust given to and from the Root Certification Authority.

  • Of course I would not have permission to sign another certificate at the end of a certificate I bought from VeriSign. Though certificates are just files, and you can easily modify a certificate using some terminal commands, you could modify a google certificate. A browser only checks the root CA certificate. It does not check other certificates, making any other forged certificates in the chain valid. If this is not true, please reply to this comment. Oct 20, 2014 at 3:24
  • @JavaIsCool Each certificate has a cryptographic hash of its other content; indeed this hash is what gets signed by its parent certificate. As such, modifying the contents of the certificate would require re-signing of the certificate by the private key of parent certificate. The browser definitely checks each certificate up the chain (or down depending on code implementation) for who signed each hash digest and whether the ultimate self-signed root node is trusted by the computer. Oct 20, 2014 at 3:40
  • OK, but how can the browser, after decrypting the digital signature to get the hash with the root certificate's public key verify that the hash for google.com is not a hash that does not match the certificate? Hashes cannot be changed back to an original value. Oct 20, 2014 at 4:43
  • @JavaIsCool The browser: 1) Checks that the claimed hash in the certificate is correctly signed; 2) Calculates the actual hash; 3) Compares the two. The hashes generated in Steps 1 and 2 deliberately exclude the hash value itself to avoid recursion of this sort. Oct 20, 2014 at 5:05
  • @JavaIsCool There is however a lack of guaranteed coordination between Root Certification Authorities; so in theory duplicate google.com certificates can be created by any trusted Root CA. This is part of the overall concern regarding Root CAs that happen to be governments or within the jurisdiction of FISA-style gag orders. Oct 20, 2014 at 5:08

You are missing a very important part of a Digital Certificate here. That part is Digital Signature. Basically, a Digital Certificate consists of 3 parts:

  1. A public key.
  2. Certificate information. ("Identity" information about user, such as name, user ID, and so on.)
  3. One or more digital signatures.

A digital signature is an encrypted hash of the certificate. It is basically a digest (e.g. SHA-1) of the certificate itself, singed (verified) by the private key of the CA. This is what tells your browser that this certificate is verified by someone (someone your browser can also trust).

As you said, you can easily take a certificate and change it. But what you really can't change here is this digital signature (since you don't have the private key belonging to that trusted someone). Hence, your browser will immediately detect it because it will not be able to verify the digital signature.

  • I know. But only the digital signature for the root certificate is verified. Oct 20, 2014 at 4:33
  • No. This hash is included in every cert and singed by its parent cert. A root cert is self-signed however. Browsers verify all these signatures properly. Oct 20, 2014 at 5:07

You must log in to answer this question.

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