HTTPS in Practice

Your site has a valid certificate and an A rating from every scanner, and the last hop of every request still travels in plain text. This is not a contradiction, it is the standard architecture: TLS terminates at a load balancer or reverse proxy, which decrypts, and then forwards to your application over the internal network. Whether that is fine or alarming depends entirely on what that internal network is — and knowing which, for a system you are responsible for, is what this track builds.

It starts with the serving architectures themselves: terminating at the edge, passing through to the application, or re-encrypting on the internal hop, and what each one means for where plaintext exists, which component holds the private key, and what an attacker who lands inside the perimeter gets. From there it covers what the browser does with the result. Secure contexts are the rule that gates capabilities like service workers and the Web Crypto API on an origin being trustworthy, which is why a feature that works on localhost can vanish when you open the same app over a plain-HTTP address on your local network. That is a real failure mode, not a hypothetical one, and recognising its signature saves an afternoon.

Then mutual TLS, where the client presents a certificate too, so that both ends prove identity rather than one — the foundation P58 builds service-to-service authentication on. The track finishes with the capstone that gives the domain its point: assembling the pieces from P52 and P53 into one working secure channel. Key agreement, authentication, authenticated encryption of the payload, integrity checking on the way out. The primitives stop being separate exercises at that moment and become a protocol you have built.