HTTPS is used to ensure data transmission security, improve user trust, and meet search engine ranking rules. As one of the current popular web servers, the HTTPS configuration of nginx seems simple but still needs to pay attention to a lot of details. From certificate selection to encryption suite tuning, from automatic renewal to performance bottleneck breakthrough, any environment is related to security.

The core of HTTPS is the SSL/TLS certificate, and obtaining and managing the certificate is the first step in the configuration. For individual sites or small and medium-sized businesses, free certificates from Let's Encrypt are the best option, and their automated tool Certbot quickly completes certificate applications and Nginx configuration. In the Ubuntu OS, run the following command to complete the basic installation:

sudo apt update  
sudo apt install certbot python3certbotnginx  
sudo certbot nginx d example.com d www.example.com  

This process automatically modifies the Nginx configuration, adds the certificate path, and enables port 443 listening. However, the configurations generated by automated tools often only meet basic requirements, and the production environment needs to be further optimized. The core of the basic HTTPS configuration is the setting of the server block. Here is a template for compatibility and security:

nginx  
server {  
listen 443 ssl http2;  
server_name example.com www.example.com;  
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;  
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;  
# Protocol and suite configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHEECDSAAES128GCMSHA256:ECDHERSAAES128GCMSHA256:ECDHEECDSAAES256GCMSHA384:ECDHERSAAES256GCMSHA384;  
ssl_prefer_server_ciphers on;  
# Performance optimization
ssl_session_cache shared:SSL:10m;  
ssl_session_timeout 1d;  
ssl_session_tickets off;  
# Safety Head
add_header StrictTransportSecurity "maxage=63072000" always;  
add_header XContentTypeOptions nosniff;  
add_header XFrameOptions DENY;  
# Other service configuration
root /var/www/html;  
index index.html;  
}
# HTTP forces a jump to HTTPS
server {  
listen 80;  
server_name example.com www.example.com;  
return 301 https://$host$request_uri;  
}

This configuration explicitly disables proven insecure TLS versions 1.0/1.1, selects the encryption suite widely supported by modern browsers, and forces clients to use HTTPS connections via the HSTS header. However, it should be noted that the maxage setting of HSTS is too long, which may cause the rollback failure. It is recommended to set it to 604800 (one week) at the initial stage, and then extend it to two years after confirming that it is correct.

Certificate chain integrity is a common point of failure. If an intermediate certificate is not included in the Nginx configuration, some clients (such as older versions of Android) will report an error because they cannot build a full trust chain. The certificate chain can be verified with the following command:

openssl s_client connect example.com:443 showcerts  

The output should contain server certificates, intermediate certificates, and root certificates. When using the Let's Encrypt certificate, fullchain.pem already contains the necessary chains, but if you use certificates issued by other cas, you need to manually concatenate the intermediate certificate.

Performance optimization is an important part of HTTPS implementation. TLS handshakes increase server load, which can be significantly reduced with the following strategies:

1. Session reuse:

nginx  
ssl_session_cache shared:SSL:50m;  
ssl_session_timeout 1d;  

The shared session cache allows multiple worker processes to reuse the same session, reducing duplicate key negotiation.

2. OCSP Stapling:

nginx  
ssl_stapling on;  
ssl_stapling_verify on;  
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;  
resolver 8.8.8.8 8.8.4.4 valid=300s;

The OCSP query result is cached on the server, preventing the client from directly sending requests to the CA and reducing latency.

3. TLS 1.3 takes precedence:

As the latest version of the protocol, TLS 1.3 reduces the handshake step and enables "1RTT" or even "0RTT" connections. However, it should be noted that 0RTT May be at risk of replay attacks, and sensitive operations should be disabled:

nginx  
ssl_early_data off;  

Automatic renewal is the lifeblood of certificate management.manual renewal is easy to forget. Use crontab to set scheduled tasks:

0 3    /usr/bin/certbot renew quiet posthook "systemctl reload nginx"  

Check certificate expiration at 3 am daily and automatically reload Nginx configuration after renewal. When a page loads over HTTPS, but sub-resources (such as images, JS) use HTTP links, the browser blocks the loading or prompts a warning. Solutions include:

1. Content rewrite:

nginx  
sub_filter 'http://' 'https://';  
sub_filter_once off;  

Replace the HTTP link in the response content with HTTPS.

2. CSP header restrictions:

nginx  
add_header ContentSecurityPolicy "defaultsrc https: 'unsafeinline' 'unsafeeval';" ;

Force all resources to be loaded through HTTPS.

Security reinforcement needs to be promoted in multiple dimensions. In addition to the basic configuration, should also:

Disable weak passwords, key rotation, certificate transparency monitoring, and compatibility with older clients. Compatibility mode can be turned on temporarily:

nginx  
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;

However, the intrusion detection must be strengthened simultaneously and the client upgrade must be promoted.