In common architecture, Nginx takes port 443, provides domain certification, and sends the request from the internal network to the app. The main difficulty of initial issuance is not: the hostname is compatible, private key is protected, the extension is indefinite, the proxy reloads, and the certification test is actually visible from the Internet.
Quick answer:First, clear your DNS and domain ownership. Depending on the circumstances, use ACME HTTP-01 or DNS-01, or a validated certificate. Leave the full chain and private key read-only and restricted to proxy; redirect HTTP to HTTPS as per policy; schedule renewal and controlled reload; monitor expiry and chain from outside.
At what point will TLS terminate?
For multiple apps on a host, termination in the reverse proxy simplifies domain management, certificate and redirect. A proxy to app connection can be on the same HTTP host internal network, if the threat model accepts it. If traffic between hosts or uncertain networks is moving, check the internal TLS or equivalent protection mechanism separately.
Check the domain and DNS before the certificate
A certificate must cover the actual hostname of the browser. Match the A/AAAA, CDN, load balancer and origin record with the request path. If IPv6 goes to another host, users may see a different certificate. Redirect from HTTP to HTTPS is also only valid when HTTPS is ready for the same hostname.
HTTP-01 or DNS-01?
In ACME HTTP-01, authentication of the domain's HTTP path is performed; the port and routing challenge must be in place. DNS-01 is validated by a TXT record of domain ownership and is required for the wildcard. The choice between these depends on the DNS provider, API access, CDN topology, and wildcard requirements.
When the certificate is pre-made
First, check the domain name, the time of validity, the export chain, and the certificate and key pairing with the appropriate tool.fullchainAnd don't copy the private key into an image or repository. Keep it on a limited-access host or secret store and mount it read-only to a proxy container. If you've got a wildcard certificate from a vendor, the extension cycle may be different from Certbot/ACME; don't assume it automatically extends.
Private key and user container licenses
The private key should be read-only for the process that provides TLS. Too open permission is not the solution for the error. If the proxy is run with a non-root user, configure the proprietary, group, or secret mechanism so that the same process has the right to read, not all host users.
Example of the logical path of Compose
Define a volume or bind mount read-only for the certificate in the Nginx service; the app only sees the internal network and does not receive the key. Ports 80 and 443 are published only for proxy. If you have ACME HTTP-01, the challenge path should be in place in the routing proxy and the shared, writeable output process.
Header related to HTTPS
After termination, the proxy must transfer the original scheme to the app, usually with header such asX-Forwarded-ProtoThe program should only rely on a proxy-based database, otherwise the client can forge the header. If the program has a redirect loop or URLs are created HTTP, check the framework's proxy-awareness settings in addition to Nginx.The Nginx guide to DockerIt explains the boundary of trust.
HTTP to HTTPS and HSTS
Enable redirect after verifying the validity of the certificate and the 443 path. HSTS limits the browser to HTTPS for a set period of time; promptly making a mistake or preload can make it difficult to recover from the TLS error. First check the domains and subdomains, old services, and other panels.
An extension is not just about writing a new file.
The renew process must report the error, put the new valid file on hold, and load it without unnecessary interruption. Many proxies do not provide the new certificate until reload after replacing the file. Test the config before reloading and then see the certificate provided from the outside. If your deployment has a specific symlink or volume, make sure that the container actually sees the new file after renewal.
How do we test Renewal?
- Document the issuance and ownership of the renew process.
- Run a dry-run or equivalent provider test in a safe environment.
- Simulate/check DNS errors, port closures or lack of file authorization.
- Record the proxy config and reload test results.
- Check the certificate provided from outside after reloading with the correct hostname.
- Set the expiry alert independent of job renewal.
Dry-run certification is not the actual deployment test site; renewal may be successful but the proxy will still read the old file. Warn expiry with a distance that is sufficient to correct DNS or authentication.
CDN and two TLS connections
If the CDN is a proxy front, the TLS browser to the CDN and TLS CDN to the origin are two separate paths. The certificate the user sees may differ from the origin certificate. flexible or HTTP modes from CDN to origin can complicate security and redirect; select an appropriate end-to-end connection policy. To detect, separate each path and do not place the CDN-related secret in the app for no reason.
Why do I still see the certificate error?
- The certificate does not cover the hostname or the root domain remains from the wildcard.
- Full chain is incomplete.
- The server/client time or credit time is in trouble.
- DNS goes to another proxy; check IPv4 and IPv6 separately.
- The proxy has not reloaded since the extension.
- CDNs provide an older certificate or an invalid origin.
Before replacing a certificate, check the DNS and SNI destination. Replacing the correct file on the wrong host has no effect on the user. Compare Nginx log and external testing tools at a time.
Independent monitoring of the
The important metric of the expiration date of the Internet-provided certificate is the validity of the hostname/chain and the result of the last renewal. The presence of a new file on disk is not sufficient. A warning should be set for important domains, subdomains, and appropriate CDN/origin paths.The server monitoring guideIt puts this alongside DNS and HTTP security.
Costly mistakes.
Placing a private key in an image, opening its license to everyone, relying on renew without reload, assuming root domain coverage by wildcard, adding HSTS before all subdomains are ready, and ignoring IPv6 are common errors.
When do you need special assistance?
If you have multiple domains, wildcards, CDN, proxies and in-house services, prepare a TLS route map and rollback before changing the certificate.The application is Dockerized.It can coordinate termination, secret, renew and external testing with network design and deployment.
Common Questions
Does each container require a separate certificate?
No, often the common proxy terminates the public TLS. Internal TLS depends on the threat model and network path.
Does the wildcard cover the main domain?
Not automatically; check the SAN names of the certificate and have a separate coverage for the root domain.
Why is Certbot successful but does the browser see the previous certificate?
The proxy may not be reloaded, the mount may not see a new file, or traffic may be going to another CDN/host.
Can I put a private key in the image?
No, the image and its layers are distributed and maintainable. Manage the key outside the image with limited access.