A browser can show a secure HTTPS connection even when an application sends secrets to a destination it should not trust. HTTPS protects traffic between the browser and the server it connects to. It cannot tell you whether that destination is trustworthy or how the server handles data once it arrives. That distinction matters when working with Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS).
“SSL certificate” is still a common phrase, but modern secure connections use TLS, not the obsolete SSL protocols. For developers, the job is to use a current TLS implementation, verify the server’s identity, and know where that protection ends.
What TLS does for a connection
TLS protects data in transit between two endpoints. With HTTPS, those endpoints are usually a client and a web server. It provides three important properties:
- Confidentiality: someone observing the network should not be able to read the protected application data.
- Integrity: changes to protected data in transit can be detected.
- Authentication: the client can check that the server presents a certificate valid for the hostname it intended to reach.
TLS does not encrypt data after it reaches the server, fix an insecure login flow, or make malicious content safe. Nor does it ordinarily hide the destination IP address, traffic volume, or all connection metadata. It is secure transport, not a complete application security system.
From connection to encrypted request
Before sending an HTTP request over TLS, the client and server perform a handshake. In a typical modern connection, the client offers supported TLS versions and cryptographic options. The server selects compatible options and sends a certificate chain. The client checks the chain and the requested hostname; both sides then establish shared session keys. Those keys protect the application data that follows.
Public-key cryptography helps establish or authenticate the connection, while efficient symmetric encryption protects the bulk of the data. Modern TLS also uses ephemeral key exchange for forward secrecy: obtaining a server’s long-term private key later should not, by itself, reveal past sessions captured on the network. Handshake messages vary by TLS version, so application code should use a maintained TLS library rather than implement the exchange directly.
HTTP over TLS is HTTPS, but TLS is not limited to browsers. A database client, for example, may establish a TLS connection before sending queries. It still needs to authenticate the server it meant to reach.
Certificates answer a specific question
A server certificate binds a public key to an identity, commonly a DNS name. A certificate authority (CA) signs it, sometimes through an intermediate CA. The client builds a chain to a trusted root and checks that the certificate is currently valid, appropriate for server authentication, and valid for the requested hostname. That hostname check uses the names in the certificate’s Subject Alternative Name field.
A successful check means the connection is authenticated for that name under the client’s trust policy. It does not prove the website’s claims or show that its code is free of vulnerabilities. An attacker can get a valid certificate for a domain they control; a padlock is not a reputation signal.
A common development snag is connecting to a local service by IP address when its certificate covers only a DNS name. Connect using a covered name, or issue a suitable development certificate through an appropriate local trust process. Disabling certificate verification may make the error disappear, but it also prevents the client from distinguishing the intended server from an impersonator.
Public trust, private trust, and self-signed certificates
A public-facing site normally uses a certificate trusted by common browsers and operating systems. An internal service can use a private CA if managed clients are configured to trust it. A self-signed certificate can work in an isolated development environment, but clients will not trust it automatically. Installing a development CA changes which certificates a machine accepts, so limit and protect that trust carefully. Never distribute the CA’s private key with an application.
Configuration choices developers control
Most applications should use a maintained web server, reverse proxy, platform service, or standard language TLS library. Do not enable obsolete SSL versions or TLS 1.0 and 1.1. TLS 1.3 is a strong default where supported; TLS 1.2 may still be needed for compatible clients. Prefer the platform’s current, well-maintained cipher settings over an unfamiliar custom list.
- Protect private keys: restrict access to the service account and authorized administrators. Do not commit keys or certificate bundles containing private keys to source control.
- Renew before expiry: automate renewal where possible, then check that the service actually loads the replacement certificate.
- Use the correct names: cover every hostname clients are expected to use without relying on broad wildcard certificates unnecessarily.
- Keep verification enabled: HTTP clients, database drivers, and service-to-service calls need certificate and hostname checks too.
- Redirect HTTP carefully: if a web service accepts plain HTTP to redirect visitors, do not accept credentials or sensitive requests on that unprotected route.
For browser-based applications, HTTP Strict Transport Security (HSTS) can tell compatible browsers to use HTTPS on future visits to a hostname. Introduce it deliberately: a long policy or one that includes subdomains can disrupt services that are not ready for HTTPS. HSTS does not replace a valid certificate or sound server configuration.
Where encryption ends matters
TLS may terminate at a reverse proxy or load balancer rather than inside the application process. The proxy decrypts the request and forwards it. If the next hop crosses an untrusted network or a different security boundary, it may need its own TLS connection. Document each hop; HTTPS in the browser does not necessarily protect the entire route to the database.
Applications behind proxies also need to treat forwarded connection information carefully. A header claiming the original request used HTTPS is trustworthy only if it comes from a proxy the application is configured to trust. Otherwise, a client may be able to supply misleading values, affecting secure redirects, cookie settings, and generated URLs.
Set sensitive browser cookies with the Secure attribute so browsers send them only over HTTPS. HttpOnly and an appropriate SameSite setting address different risks; TLS does not replace them. A page delivered over HTTPS should also avoid loading active resources over plain HTTP, which can cause mixed-content failures or exposure.
Debugging a TLS failure without hiding it
A failed connection gives you something to investigate. Before changing settings, record the hostname, port, time, client error, and whether the failure occurs in a browser, command-line client, or application. Diagnose only services you operate or are authorized to test. Common causes include:
- Expired certificate: check its validity period and whether the server is still presenting an old certificate after renewal.
- Hostname mismatch: compare the requested hostname with the certificate’s covered names.
- Incomplete chain: check whether the server sends the required intermediate certificates.
- Untrusted issuer: confirm which CA store that client uses, especially in containers or custom runtime environments.
- Protocol mismatch: check whether the client and server share a supported TLS version and configuration.
Check the system clock, too. Certificate validity depends on dates, and a badly misconfigured clock can make a valid certificate appear not yet valid or expired. Logs may show whether the failure happens during certificate validation or earlier in negotiation. Keep private keys, session secrets, and sensitive request contents out of those logs.
For a small development check, create a test service with a hostname covered by its certificate, connect using that hostname, and leave client verification enabled. If it works only with an “ignore certificate errors” option, investigate the trust chain or hostname instead of keeping the option.
