The key point
TLS protects data in transit and helps browsers authenticate the hostname. It does not certify that a business or its content is trustworthy.
Encryption in transit
TLS encrypts traffic between the browser and the TLS endpoint so that network observers cannot read passwords and form data in plain text. The certificate participates in authentication. The TLS handshake establishes the keys used for the connection.
Identity and domain names
A public certificate binds a public key to validated domain names. DV checks domain control. OV and EV add organisation checks. The browser also checks the name, validity and trust path before accepting the connection.
What HTTPS does not cover
HTTPS does not scan your application for malware, secure a database or prove that a seller is honest. If TLS ends at a CDN or load balancer, configure and protect the separate connection to the origin as well.
Worked example
A sign-in page on shop.example.com
Your visitor opens the sign-in page over HTTPS. The browser checks the certificate and negotiates an encrypted TLS connection before sending the password. If a CDN or load balancer terminates TLS, its connection to your origin needs its own protection.
- Encrypted connection
- Someone on the network cannot read the password in plain text while it is in transit.
- Correct hostname
- The certificate must cover shop.example.com, even if example.com redirects there.
- Application security
- Account access, database security and phishing protection still need separate controls.
Your next steps
- List every hostname visitors use, including the address before a redirect.
- Choose domain coverage and validation level separately, then create a CSR for that coverage.
- Install the certificate and intermediates, enable HTTPS and check the deployed hostname.