A certificate is often described as making a site secure, which leads people to trust a padlock on a site that should not be trusted at all. It proves two specific things, and neither of them is that the business is honest.

What it proves

  • You are talking to the holder of this domain name. Somebody demonstrated control of the domain to a certificate authority.
  • Nobody in between can read or change the traffic. The connection is encrypted and its integrity is checked.

What it does not prove

  • That the company behind the domain exists, or is trustworthy.
  • That the site is not a phishing page - phishing sites have valid certificates, and most of them do.
  • That the application is secure. A certificate protects the wire, not the code behind it.

How the proof is made

Three ways, all of them proving control of the domain: serving a specific file at a given URL, answering on port 443 with a specific certificate, or publishing a TXT record in DNS. The last one is the only method that can issue a wildcard.

# what a certificate says about itself\nopenssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null \\n  | openssl x509 -noout -subject -issuer -dates

The chain is the other half

Your certificate is signed by an intermediate, which is signed by a root the browser already trusts. Serve the chain incompletely and some clients cannot verify it - see an incomplete certificate chain.

Which means

Teaching customers to look for the padlock as proof of legitimacy is now misleading advice. It proves the connection, not the counterparty. The domain name in the address bar is the thing worth reading.

A free certificate proves exactly as much as a paid one - see Let's Encrypt against a paid certificate.