Configure a proxy certificate by first deciding which connection the proxy will secure. For client-to-proxy TLS termination, install a certificate whose names match the public proxy hostnames and configure the proxy to present the leaf certificate followed by its intermediate certificates. If the proxy then connects to an HTTPS upstream, configure that second TLS connection separately: validate the upstream certificate against a trusted CA, and provide a client certificate only if the upstream requires mutual TLS (mTLS).
Choose where TLS terminates
A proxy can handle TLS on one connection or both. Decide which design you need before installing files; a certificate on the public listener does not automatically secure or authenticate the proxy’s connection to its backend.
- Termination at the proxy: the client establishes TLS with the proxy. The proxy presents its server certificate, decrypts the request, and typically forwards it to an upstream over a separate connection. That upstream connection may be HTTP or HTTPS.
- TLS passthrough: the proxy forwards the encrypted client connection without terminating TLS. The upstream presents the certificate to the client. The proxy does not use a server certificate for that connection in the same way it would for termination.
- Termination plus re-encryption: the proxy terminates client TLS and starts a new TLS connection to the upstream. Configure and verify the two handshakes independently; the certificate and trust settings for one leg do not configure the other.
- Forward proxy with mTLS: clients connect through a forward proxy and authenticate with client certificates. This is distinct from a reverse proxy serving a website to visitors.
For a reverse proxy, the usual starting point is termination at the edge. Add upstream TLS when the backend connection must be encrypted, and add upstream client authentication only when the backend requests it. The exact capabilities and configuration syntax depend on the proxy and its version.
Prepare the certificate and key
- List every public proxy hostname. Check that the certificate’s Subject Alternative Name (SAN) covers each hostname clients will use. A certificate for
proxy.example.comdoes not necessarily coverwww.example.com. - Obtain a certificate and its matching private key. Keep the private key restricted to the proxy’s required account or master process. It must be readable by the process that loads it, but should not be broadly readable or exposed in source control, logs, or public directories.
- Build the presented chain in the correct order. Configure the leaf/server certificate first, followed by the intermediate certificate or certificates needed to link it to a trusted authority. The server certificate is public and is sent to connecting clients; the private key is not.
- Check the pair and permissions before deployment. Confirm that the private key matches the certificate and that the proxy can read the configured files. Use the proxy’s documented validation command or deployment checks for the exact version you run.
An incomplete chain often appears as a trust error on some clients even when the leaf certificate itself is valid. Do not assume every client will retrieve missing intermediate certificates automatically; configure the chain the proxy is expected to present.
Recommended Free Tools
#1 Best Overall
Configure NGINX for reverse-proxy TLS termination
In this example, NGINX listens for HTTPS on port 443 and serves proxy.example.com. The certificate file is a chain file with the leaf certificate followed by intermediates; the key is separate.
server {
listen 443 ssl;
server_name proxy.example.com;
ssl_certificate /etc/ssl/certs/proxy.example.com.chained.crt;
ssl_certificate_key /etc/ssl/private/proxy.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
}Replace the hostname and paths with your own. Keep the key’s permissions restricted while ensuring the NGINX master process can read it. Before applying a change, validate the configuration using the command documented for your installed NGINX version, then reload through your normal service-management procedure. A reload lets the running service load the new files without treating a successful configuration edit as proof that the certificate is being served correctly.
Configure TLS from NGINX to an HTTPS upstream
When the backend uses HTTPS, NGINX is a TLS client on that leg. It should validate the upstream certificate using a trusted CA file and verify the upstream identity where supported. If the upstream requires mTLS, also configure a client certificate and matching key for NGINX to present.
location / {
proxy_pass https://backend.example.com;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-bundle.pem;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;
proxy_ssl_certificate /etc/ssl/certs/proxy-client.crt;
proxy_ssl_certificate_key /etc/ssl/private/proxy-client.key;
}The trusted CA file is for validating the upstream’s server certificate; it is not the proxy’s public-facing certificate. The client certificate and key are needed only when the upstream asks NGINX to authenticate itself with mTLS. Ensure the upstream certificate identity matches the name NGINX uses to connect. Confirm the relevant verification and name-matching behavior against the documentation for your NGINX release before production use.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #2
- Used Book in Good Condition
Configure mTLS on an NGINX forward proxy
For an HTTP CONNECT forward proxy, the listener needs its own server certificate and key. To require client certificates, configure a CA certificate used to verify clients and turn on client verification. NGINX documents mTLS as authentication in both directions; for its HTTP CONNECT proxy, mTLS is the supported authentication method.
listen 10.10.1.11:3128 ssl;
ssl_certificate /etc/ssl/certs/forward_proxy_server.crt;
ssl_certificate_key /etc/ssl/private/forward_proxy_server.key;
ssl_client_certificate /etc/ssl/certs/forward_proxy_client_ca.crt;
ssl_verify_client on;
ssl_verify_depth 1;
ssl_protocols TLSv1.2 TLSv1.3;Place these directives in the appropriate NGINX context for the configuration you are building, and check context and directive support for your version. The server certificate authenticates the proxy to clients; the client CA is a trust anchor for authenticating clients. Distribute client certificates and keys securely, and issue them from a CA whose trust scope is appropriate for this proxy.
Configure HAProxy and Envoy
HAProxy: bind a certificate PEM
HAProxy’s documented pattern uses a TLS-enabled frontend bind and a certificate PEM. The PEM normally contains both the certificate and private key; protect the bundle accordingly.
crt-base /etc/haproxy/ssl/certs/
key-base /etc/haproxy/ssl/private/
frontend example
bind :443 ssl crt /etc/haproxy/ssl/certs/example.pem
default_backend webserversHAProxy can also be given a certificate directory so SNI can select a certificate whose CN or SAN matches the requested domain. If several names share an address, include appropriate certificates and confirm selection with clients that send each hostname as SNI. Validate the exact certificate-file and directory behavior against the HAProxy version and configuration in use.
Free tools Windows power users keep installed
One-click scans. No signup required.
Envoy: configure downstream and upstream TLS separately
Envoy supports TLS termination on downstream listeners and TLS origination to upstream clusters. Its configuration refers to a certificate chain and private key for a static certificate, and a validation context supplies trusted CAs for upstream validation. Depending on the deployment, the validation context can also express subject-name checks, pinning, revocation checks, and other TLS controls. Envoy supports client certificates, chain and subject-name verification, hash pinning, CRLs, and ALPN; choose controls that match the trust model rather than assuming that enabling encryption alone verifies the peer.
Envoy deployments may use a secret-delivery mechanism rather than static local files. The right loading and rotation model depends on the installation. Keep the downstream serving identity distinct from upstream trust configuration, and verify the schema and behavior for the Envoy release you deploy.
Use SNI when hostnames share an address
Server Name Indication (SNI) lets a TLS client indicate the hostname it is connecting to during the handshake. A proxy hosting several TLS names on one address can use that name to select the matching certificate. The certificate still needs to cover the requested hostname, and the client must send the intended name.
When configuring multiple names, check both sides of the mapping: the proxy has a certificate for each required hostname, and clients connect using the hostname rather than only an IP address. A client that omits or sends the wrong SNI name may receive a default certificate, which can cause a hostname validation failure even though another correct certificate is installed.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #4
Automate issuance, renewal, and reload
Certbot can obtain certificates through certbot or certbot certonly, install them for NGINX or Apache, and keep active certificate files under /etc/letsencrypt/live/. Its renew action checks installed certificates for impending expiry and attempts renewal. A certificate being renewed on disk is not enough: the proxy must reload or otherwise load the new files.
- Choose an issuance method. Select an authenticator that can prove control of the hostname in your environment. If renewal depends on manual authentication, it will require an authentication hook for unattended renewal.
- Configure a deploy or post-renewal hook. Have the hook validate the proxy configuration and reload the relevant service after successful renewal. Avoid reloading on a failed issuance or deploying an invalid configuration.
- Test before relying on automation. Exercise renewal in a staging environment, confirm that the hook runs, and verify that the proxy serves the renewed certificate afterward.
- Monitor the outcome. Check certificate expiry and renewal failures through your existing operational monitoring. Do not treat an installed renewal timer or scheduled command as evidence that clients are receiving the current certificate.
The precise Certbot authenticator, hook syntax, service command, and reload behavior depend on the operating system and installation. Use the Certbot and proxy documentation for those specific details.
Verify both TLS handshakes
- Inspect the public certificate and confirm its SAN includes every hostname clients use.
- Confirm the private key matches the leaf certificate and is readable only by the necessary proxy process or account.
- Check that the proxy presents the leaf certificate first and the required intermediates after it.
- Test client-to-proxy TLS with the hostname and SNI clients will actually use.
- For HTTPS upstreams, test proxy-to-upstream TLS independently; confirm the trusted CA is installed and hostname verification is enabled where supported.
- For mTLS, verify that the expected client certificate is accepted and that an untrusted or missing client certificate is rejected when policy requires one.
- Exercise renewal in staging, then verify the controlled reload and the certificate served after renewal.
Troubleshooting common certificate failures
Clients report an untrusted or incomplete chain
Check that the configured chain file contains the leaf certificate followed by the required intermediate certificates. Confirm the proxy is loading that file, rather than a leaf-only file or an outdated path. Test from a client environment that reports the peer chain, because a browser’s cached intermediates can hide a server-side omission.
The browser reports a hostname mismatch
Compare the exact hostname in the address bar with certificate SAN entries. If multiple sites share an address, inspect SNI configuration and ensure the client connects with the intended DNS name. A valid certificate for a different site is still the wrong certificate.
Best Value
The proxy cannot start or reload after a certificate change
Check file paths, permissions, key-certificate pairing, and configuration syntax. The private key must remain protected but readable by the process that loads it. Run the installed proxy’s configuration validation step before a reload, and confirm the service actually completed the reload.
The upstream connection fails although the public site certificate works
Diagnose the proxy-to-upstream leg separately. Check that the configured CA bundle trusts the upstream issuer, that the upstream hostname matches its certificate, and that the proxy is using the expected hostname. If the upstream requires mTLS, confirm that NGINX or the relevant proxy presents the correct client certificate and key.
Only some hostnames receive the right certificate
Check SNI names, certificate coverage, and the proxy’s multi-certificate selection behavior. Test every hostname rather than only the default virtual host. Also confirm DNS directs those names to the intended proxy.
A renewed certificate is not visible to clients
Confirm renewal completed, the active file path points to the renewed files, and the deploy hook validated and reloaded the proxy. Then inspect the certificate served over a fresh connection. A renewal process that updates files without reloading the service can leave the running proxy serving the previous certificate.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Or skip the browser setup
ScreenshotNeo is a website screenshot API, not a TLS certificate validator or proxy-configuration tool. After your site is reachable, it can capture a page for a visual smoke check; use the handshake and certificate checks above to verify TLS itself. Its request can remove cookie/consent banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, and cache hits are not billed, and each response identifies the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpFor a visual check of your own site, replace https://stripe.com with its public URL. Sign up for 1,000 free screenshots a month, with no card required.
Frequently Asked Questions
Can a successful screenshot prove that a proxy’s TLS certificate is valid?
No. A screenshot shows a rendered page, not whether the proxy served the complete intended chain or correctly validated the upstream. Check the relevant TLS handshakes and certificate identities directly.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
