TLS for Proxy Operators: Chains, Ciphers, Renegotiation

TLS termination concentrates risk and responsibility at the proxy, and operators get blamed for every scary browser warning or stalled handshake. This post covers the three TLS topics that actually decide whether your edge works: reading a certificate chain, choosing ciphersuites, and handling renegotiation.

Reading a certificate chain

A server presents more than one certificate during a handshake. The chain is leaf first, then one or more intermediates, closing at a root that both sides trust. A proxy needs the full chain to complete verification; serving only the leaf is the most common cause of the "unable to get local issuer certificate" error clients report.

openssl s_client -connect api.example.com:443 -showcerts </dev/null 2>/dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{print}'

The output contains multiple PEM blocks. Install them in order leaf, intermediate, root onto the proxy, and keep the private key separate with restrictive permissions. A missing intermediate makes browsers warn; a missing chain makes stricter clients such as OpenSSL and curl refuse outright.

Chain order

• Leaf: the certificate for your hostname, matched by SAN entries, not just the Common Name.
• Intermediate: issued by the CA, signed by intermediate or root; browsers trust it because they trust the root.
• Root: the trust anchor, kept out of the serving chain unless a legacy client requires it.

Choosing ciphersuites

A TLS 1.2 ciphersuite names key exchange, authentication, encryption, and MAC in one string, for example ECDHE-RSA-AES128-GCM-SHA256. TLS 1.3 simplified this: cipher suites no longer include the key exchange, and obsolete constructions such as CBC modes were deleted. For an edge proxy, prefer AES-GCM and CHACHA20 suites and leave the exotic ones off.

openssl ciphers -v 'HIGH:!aNULL:!MD5' | head -n 12

A useful mental model for suites

• Key exchange: ECDHE (forward secrecy) is the safe default; RSA key exchange should be considered legacy.
• Encryption: AES-GCM or CHACHA20-POLY1305; both are authenticated, both survive well on generic hardware.
• MAC: suites now use AEAD, so the MAC is part of the cipher, not a separate GCM-vs-MD5 decision.

Choose a small explicit list instead of a long expression. Long lists look impressive and make debugging harder, and the first suite that matches is the only one you actually tested.

TLS 1.3 and renegotiation

Client-initiated renegotiation in TLS 1.2 lets either side renegotiate parameters mid-session, a feature that was abused to smuggle requests past security appliances by racing the renegotiated state. Modern stacks disable or limit it, and TLS 1.3 removed renegotiation entirely, folding key updates into the protocol itself as a first-class operation. On the proxy, default to TLS 1.2 and 1.3 and document why you accept anything older.

Chain flow

A sane proxy TLS profile

Pin versions and suites explicitly so the config reads as an intent rather than an accident:

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate     /etc/netbay/tls/fullchain.pem;
    ssl_certificate_key /etc/netbay/tls/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
}

Verify the profile from the outside with curl before trusting a browser:

curl -sSI https://api.example.com/health | head -n 5

Takeaway

Treat the chain as three moving parts, not a blob: leaf, intermediates, and a trust anchor you can verify with openssl. Keep TLS 1.2 and 1.3, prefer a short list of AEAD suites, and leave legacy renegotiation only where a compliance requirement forces it. Test the whole chain on a Netbay VPS before pointing a real domain at it; the complete walkthrough lives at netbayhosts.in.