Last active
October 5, 2025 07:59
-
Star
(343)
You must be signed in to star a gist -
Fork
(107)
You must be signed in to fork a gist
-
-
Save nrollr/9a39bb636a820fb97eec2ed85e473d38 to your computer and use it in GitHub Desktop.
NGINX config for SSL with Let's Encrypt certs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # UPDATED 17 February 2019 | |
| # Redirect all HTTP traffic to HTTPS | |
| server { | |
| listen 80; | |
| listen [::]:80; | |
| server_name www.domain.com domain.com; | |
| return 301 https://$host$request_uri; | |
| } | |
| # SSL configuration | |
| server { | |
| listen 443 ssl http2; | |
| listen [::]:443 ssl http2; | |
| server_name www.domain.com domain.com; | |
| ssl_certificate /etc/letsencrypt/live/www.domain.com/fullchain.pem; | |
| ssl_certificate_key /etc/letsencrypt/live/www.domain.com/privkey.pem; | |
| # Improve HTTPS performance with session resumption | |
| ssl_session_cache shared:SSL:10m; | |
| ssl_session_timeout 10m; | |
| # Enable server-side protection against BEAST attacks | |
| ssl_protocols TLSv1.2; | |
| ssl_prefer_server_ciphers on; | |
| ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384"; | |
| # RFC-7919 recommended: https://wiki.mozilla.org/Security/Server_Side_TLS#ffdhe4096 | |
| ssl_dhparam /etc/ssl/ffdhe4096.pem; | |
| ssl_ecdh_curve secp521r1:secp384r1; | |
| # Aditional Security Headers | |
| # ref: https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security | |
| add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; | |
| # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | |
| add_header X-Frame-Options DENY always; | |
| # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options | |
| add_header X-Content-Type-Options nosniff always; | |
| # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection | |
| add_header X-Xss-Protection "1; mode=block" always; | |
| # Enable OCSP stapling | |
| # ref. http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox | |
| ssl_stapling on; | |
| ssl_stapling_verify on; | |
| ssl_trusted_certificate /etc/letsencrypt/live/www.domain.com/fullchain.pem; | |
| resolver 1.1.1.1 1.0.0.1 [2606:4700:4700::1111] [2606:4700:4700::1001] valid=300s; # Cloudflare | |
| resolver_timeout 5s; | |
| # Required for LE certificate enrollment using certbot | |
| location '/.well-known/acme-challenge' { | |
| default_type "text/plain"; | |
| root /var/www/html; | |
| } | |
| location / { | |
| root /var/www/html; | |
| } | |
| } |
if you need to support different subdomains (eg. api. , www. , etc...) you
should duplicate the server section of your configuration and adapt
accordingly. Now when it comes to adding SSL for each of the server
sections there are a number of options you have:
- either you generate a certificate for each of the subdomains
- or you generate a wildcard certificate
- eg.
https://medium.com/@utkarsh_verma/how-to-obtain-a-wildcard-ssl-certificate-from-lets-encrypt-and-setup-nginx-to-use-wildcard-cfb050c8b33f
But reusing a certificate from another subdomain is a no-go... FQDN and
certificate must match
…On Sat, 5 Oct 2019 at 19:12, Tyrfing Mjølner ***@***.***> wrote:
This setup covers www.domain.tld, how would I do api.domain.tld in the
same config? I assume I copy the server section and amend the api server
section to become the api counter part of www, do I still use the same:
/etc/letsencrypt/live/www.domain.com/fullchain.pem or will I make a
separate one for api? Will there be an entry like: /etc/letsencrypt/live/
api.domain.com/fullchain.pem
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://gist.github.com/9a39bb636a820fb97eec2ed85e473d38?email_source=notifications&email_token=AAP5C2R7JVXJRHXUNHFH4QLQNDDGBA5CNFSM4HQGOZU2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAFZ6UY#gistcomment-3046732>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP5C2VSEWAPSL6DKUVOUJ3QNDDGBANCNFSM4HQGOZUQ>
.
Thanks for the infomation about
ssl_dhparampart, though 4096 takes too long to generate, and ashttps://mozilla.github.io/server-side-tls/ssl-config-generator/suggested, I use 2048 instead.
Thank you after all, helped a lot.use this instead it will speed it up :D
openssl dhparam -dsaparam -out dhparam.pem 4096
@AKApumkin you probably meant openssl dhparam -dsaparam -out dhparam.pem 2048 ;-)
@nrollr Nope, defiantly 4096. That command will generate the 4096 much faster. There's a good explanation of why here
thanks for this snippet!
if I'm not mistaken the acme protocol requires port 80 for the http-01 challenge. something like below should do:
server {
listen 80;
listen [::]:80;
server_name www.domain.com domain.com;
location '/.well-known/acme-challenge' {
default_type "text/plain";
root /var/www/html;
}
location / {
return 301 https://$host$request_uri;
}
}
@kmcminn actually it tries HTTPs first
You can use Mozilla SSL Configuration Generator:
https://ssl-config.mozilla.org/#server=nginx&version=1.18.0-r0&config=intermediate&openssl=1.1.1g-r0&guideline=5.6
A real-world working example:
https://github.com/vald-phoenix/gitea/blob/master/conf/nginx.conf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
use this instead it will speed it up :D
openssl dhparam -dsaparam -out dhparam.pem 4096