is the certificate signature a hash of just the public key?

Question

Is the X.509 Certificate Signature an encrypted hash of just the public key or is it a hash of more then the just the key?

Answer 1

The signature covers the certificate, not only the public key. If the signature covered only the public key, you could change any parameter (expiration date, domain name, issuer) and the signature would still be valid.

Digital signatures are not encryption: https://security.stackexchange.com/a/87373/70830

It is important, when reading the link above, to not skip words, sentences and paragraphs that are hard, or at least, if you did, to not then say you've read it when you have only tried and failed to read it.

Very insecure textbook RSA was explained in a handwavy form to non-specialists who did not need to implement it, in this bad way, by someone who thought it reduces the number of concepts and is thus easier to digest. The people who made this explanation were wrong in the 70s about RSA (at the very least because padding), but they are catastrophically wrong about modern digital signatures. There is no notion of encryption in DSA, ECDSA, EdDSA.

People have, in the decades since and even recently, naively implemented textbook RSA, thinking it is secure. Often, they later say something like "my math professor said I can implement unbreakable encryption by just using modular exponentiation, in some introductory math class, and I took a bignum library and just did it".

Textbook RSA is of course insecure, and if they learned about cryptography in a cryptography class, they would have been taught why.

We can't take out every math teacher (or documentation writer or blogger) who says this out back and shoot them. Because we need math teachers (and maybe even bloggers). But we really need to teach math teachers, at least new math teachers, to not talk about cryptography outside of cryptography classes that will teach people enough so they won't go out and do stupid things. Machine shop teachers understand teaching about safety, math teachers should too. But many were themselves taught in an environment that did not appreciate that there can be safety hazards in pure math. Because someone might rely on an app, a piece of math, to keep secrets that would land them in jail, or worse.

We are also getting into the general problem with updating information in people's heads and on the internet. This problem is very hard.

Often, when people learn that something they knew is actually incorrect, they would later forget the update and keep remembering the incorrect first thing they learned. So you need to keep correcting people.

The internet keeps publishing regurgitations of information that someone learned decades ago and that now we know is incorrect, and the date of the publication is new, so a reader would not know they are reading something from the 70s that has since become wrong. So we need to keep correcting publications.

This site has many separate questions and answers that boil down to someone trying to make sense of the "signature is encryption with the private key" explanation and failing (first example that came up on google). The world is full of buggy software written by people who didn't read and understand why it's wrong.

(Thanks Steffen Ullrich for the typo fix!)

Answer 2

For security purposes, a certificate's signature must sign the entire certificate (aside from the signature itself, obviously...). Otherwise, you could take a validly-issued certificate for your own domain (and for which you hold the corresponding private key), change the "Subject" (the entity - such as a domain like "yoursite.com" - that the certificate identifies) to some other entity you want to attack (like "bigbank.com"). You would then have a "valid" certificate that could be used to intercept traffic meant for somebody else, allowing you to read, modify, or forge messages in both directions.

To prevent this, all parts of the certificate that identify its owner and its purpose - the subject name, subject public key, validity period, usage values, and issuer - are included in the signature. More accurately, yes, they're all included in the hash function input, the output ("digest") of which being the thing that the actual mathematical "signing" operation is performed on. Modifying anything except the signature means the hash will change and thus the signature won't verify. Modifying the signature itself obviously invalidates it, unless you created a whole new valid signature... which you can't do without the issuer's private key.