Who Signs the Signer?

The certificate chain doesn't survive many questions - keep asking who signed what, and you end up at a root that signed itself. Most assumptions in security are, too.

Who?

Without identity verification, a man-in-the-middle (MITM) can negotiate encryption with both parties and forward traffic between them, keeping the channel encrypted to the wrong endpoint the entire time.

Certificates solve this by binding a public key to a domain name, signed by a Certificate Authority your browser already trusts.

Root CAs sign intermediate CAs, which sign the certificates servers actually use, and your browser trusts a set of root CAs that ship with the operating system because your OS vendor decided to include them.

What?

In 2011, DigiNotar, a trusted root CA, was compromised. Attackers issued fraudulent certificates for Google that every browser accepted. One link in the chain failed, and the whole thing came apart.

After DigiNotar, Certificate Transparency introduced public append-only logs that record every certificate a CA issues. Issuance can now be monitored and audited, but that's still just another entity to trust.

On corporate networks, a root CA installed on employee machines lets the network generate certificates on the fly for every HTTPS connection, decrypting and re-encrypting traffic as it passes through. Technically identical to a MITM attack, the only difference is who installed the root certificate and whether you agreed to it.

Why?

Every system has a version of the self-signed root, some assumption at the foundation that everything else is built on. The certificate chain makes it literal, and most of vulnerability research is finding the ones that aren't.