HTTPS protects a connection between a browser and a website endpoint. The protection uses TLS, the protocol that encrypts the traffic and helps verify the server. On a modern website, however, the public endpoint may forward the request to several other services. Those connections need attention too.
Understand the idea
Draw the route from the browser to the system that handles the data. Include any content-delivery service, proxy, gateway, and backend. Check where encryption ends, how the next connection is protected, and which systems may connect to the backend. A valid public certificate answers only part of this review.
- Browser
The client verifies the public endpoint.
- Edge
A proxy or gateway terminates and forwards traffic.
- Origin
The next connection and backend access also need protection.
A practical example
For example, a charity’s public site has a valid certificate at its hosting gateway. The gateway then sends private form data to an internal server. The team checks that second connection and restricts direct access to the server, instead of assuming the browser’s padlock covers the whole route.
What to do next
- Inventory every termination point. Include the public edge, origin, internal APIs, mail services, management interfaces, and older appliances. Assign a certificate owner and renewal alert.
- Use supported protocol policy. Follow current platform guidance for TLS versions and cipher configuration. Test required clients before removing compatibility, and retire obsolete exceptions on a date.
- Verify the peer. Applications should validate the certificate chain and expected hostname. Disabling verification to fix a development error removes an essential part of the protection.
- Check redirects and browser policy. Send HTTP users to HTTPS. Consider HSTS after confirming HTTPS works across the intended scope; broad subdomain or preload decisions need careful inventory and rollback planning.
- Test renewal and failure. Confirm the replacement certificate reaches the actual edge and that monitoring catches an expired, untrusted, or wrong-name certificate.
How to check the result
Keep a connection diagram and test each expected hostname and connection. A working homepage alone does not prove that certificate checks and backend access restrictions are correct.
The browser shows a padlock. Is every internal hop encrypted?
Not necessarily. The padlock describes the browser’s connection. Trace proxy-to-origin traffic and validate the certificates and access controls on those routes.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
