TLS and the chain of trust

The subject is who the certificate is for, and the issuer is who signed it. When the two are the same, the certificate signed itself, which is what self-signed means. The encryption still works, but nothing independent has confirmed that the name and the key belong together, so a browser warns rather than showing a padlock. A real site presents a chain ending at a root in your trust store.

Encryption on its own leaves a gap: an attacker could sit in the middle, encrypt one half of the conversation with you and the other half with the real site, and read everything. The certificate closes that gap by binding a public key to a name and having a trusted authority sign the binding. Without it, the padlock would prove only that you were talking to someone, not to whom.

The chain lists each certificate the server sent, numbered from zero for the leaf. The s line gives the subject, who that certificate is for, and the i line gives the issuer, who signed it. Walking the i of one entry to the s of the next is how the chain is checked. A single entry where s equals i is a self-signed certificate with a chain of one.

A root certificate is the top of a chain and is trusted because it ships in your device trust store, not because something above it signed it. From that anchor, intermediate certificates are signed down to the leaf that names the site. Verifying a site means checking each signature from the leaf back up to a root you already trust. A self-signed certificate has no anchor, which is why the check fails.