Why is it not possible to fake a digital certificate?

Question

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?

Answer 1

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.