When a client accesses an HTTPS webpage, (please correct me if I'm wrong), it just checks whether the certificate of that website has been signed by a trusted CA or not, but does not ask directly the CA something like: "ey, did you actually sign this?". Then why is it not possible to fake a digital certificate just by creating one with a signature of a well-known/trusted CA like VeriSign?

  • 4
    One does not simply include a signature from another certificate, signatures are computed per-certificate using the CA's private key, which you shouldn't have access to. – Alexander O'Mara Jul 4 '16 at 20:23
  • If signatures could be faked what would be the point of using them? – user253751 Jul 4 '16 at 23:05
  • 5
    Why the downvotes? I think the question is fair (as to understand the reason). If this question has already been answered, then mark it as duplicate, otherwise explain, please. – lepe Jul 5 '16 at 0:54
  • It doesn't have to. The CA certificate is also installed. If it signed another certificate both are trusted for obvious reasons – Ramhound Jul 5 '16 at 4:41

A digital certificate, especially the most-common X.509 format used for TLS, has a number of parts. Three of the most important are the subject name, the subject public key, and the issuer signature. The first two tell you who the certificate is for (such as "*.stackexchange.com"), and what the public key that corresponds to that entity's private key is. Spoofing these parts would let you use a certificate that was issued to you for intercepting requests to another server (by changing the subject name), or using your own public/private key pair to decrypt the key exchange and thus decrypt the entire TLS connection (by replacing the subject public key with your own public key). Therefore, the certificate needs to be protected against tampering, and the recipient of the certificate needs to be able to tell whether the certificate was spoofed or not (you could, after all, just make up the subject fields). That's where the signature comes in.

Digital signatures are created using a private key, not a public key, so only the holder of that private key can create the signature. Anybody who has the public key can verify the signature, though. Typically you create a signature of a short byte string, called a cryptographic hash digest (the output of a function like SHA-256), because public/private-key cryptography is slow (though you could, in theory, sign the entire certificate). Verifying the signature string turns it back into the original digest. If the verified signature does not match the digest of the certificate (which the client can compute themselves), then the certificate is not trusted (because it's been tampered with or has a fake signature).

Because the only entity with a CA's private key is (in theory) the CA itself, only the CA can create signatures that will verify using the CA's public key. The client doesn't need to ask the CA whether it signed the certificate; if the CA didn't sign the certificate, then the certificate wouldn't have the CA's signature on it (unless somebody else got ahold of the CA's private key, which is the kind of failure that tends to put a CA out of business). An attacker also can't just take the signature from some valid certificate X and put it on a fraudulent certificate Y, because when that signature is verified it will match the digest (hash function output) of certificate X, but not the digest of the fraudulent certificate Y (unless the attacker has found a collision in the hash function, which is why nobody trusts certificates signed with old and broken hash functions like MD5 anymore).

Clients, such as your browser, know what the CA's public key is because trusted CA certificates (which include public keys) are included with your client, or even with your operating system. Therefore, I can't just sign something with my own private key and pretend Verisign signed it; Verisgn's public key is already known to your client and wouldn't verify the signature, so you wouldn't trust the certificate. This trust is often used transitively; a root CA (like Verisign) might say "I trust this so-called intermediate CA, so I'm going to sign their certificate (including the part that says that their certificate can sign other certificates), and you should trust them as you trust me." The intermediate CA can then sign a certificate for a web site or something, which is at the bottom of a "chain of trust" that connects the web server's certificate to the root CA certificate by way of the intermediate CA.

  • 1
    Can you please explain more simply the part of why can't someone take the signature and pretend that it's his? (the part "it will match the other certificate's digest but not the fraudulent certificate's digest"). – Maroun Apr 26 '17 at 13:42
  • 1
    @MarounMaroun signatures are based on the cryptographic digest (output of a secure hash function) of the certificate. Verifying a signature takes the signature blob and the public key, and uses the key to turn the blob into a digest. If that digest matches the certificate's digest, the signature is valid. If I take somebody else's certificate and put my public key in it, or my own cert and put somebody else's hostname on it, either action will change the cert and therefore change its digest, which means the output of signature validation won't match the cert's digest anymore. – CBHacking Apr 27 '17 at 0:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.