Question

Ngnix SSL server block not to force https

Hello digitalocean users,

Is it possible to NOT force HTTPS. I have a Multi Wordpress site setup and I’m attempting to perform domain mapping that will allow me to have HTTPS and none SSL sites running from the same IP. My current SSL setup works but everytime I add a domain I’m required to create a SSL certificate to my project… what if I want to have a regular HTTP site instead?

So while my domain mapping plugin from WPMUDev has https forcing OFF. My server block does the opposite.

My port 80 server block looks like this

server { listen 80; server_name example.com www.example.com; return 301 https://$server_name$request_uri; }

If I remove the 301 redirect from the server block then all none SSL just redirect to example.com instead of the appropriate domain.

Any help would be appreciated.


Submit an answer
Answer a question...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

I got it working and my virtualhost file ended up looking like this

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /var/www/html/wordpress;
        index index.php index.html index.htm;

        server_name maindomain.com www.maindomain.com *.maindomain.com;
        ssl_certificate /etc/letsencrypt/live/maindomain.com-0001/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/maindomain.com-0001/privkey.pem;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-S$';
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_stapling on;
        ssl_stapling_verify on;
        add_header Strict-Transport-Security max-age=15768000;
    location / {
        try_files $uri $uri/ /index.php?$args ;
    }
    location ~ /favicon.ico {
        access_log off;
        log_not_found off;
    }
        location ~ /.well-known {
                allow all;
        }

Is there anything else that can be done?

I think your problem may be- because you are using add_header Strict-Transport-Security max-age=15768000; This is actually telling the browser to choose https over http for the domain name requested. No matter if your configuration files have both encrypted and non encrypted traffic, this directive tells the browser to serve https over http And you can use: return 301 $scheme://$servername$request_uri; instead of: return 301 https://$servername$request_uri; See here Also are you creating seperate nginx configuration files for each domains like /etc/nginx/sites-available/maindomain for main domain /etc/nginx/sites-available/anotherdomain for another domain? and symbolic links to sites-enabled? I’m sure you’ve done it already but still asking to make sure. This tutorial is more superior than some others in creating ssl websites with letencrypt.

Ryan Quinn
DigitalOcean Employee
DigitalOcean Employee badge
December 21, 2016

You’ll have to do a bit more than just removing the 301 redirect since the entry doesn’t have any PHP support included.

Instead, copy the contents of the SSL virtualhost in the other file in /etc/nginx/sites-enabled/ replacing the servername and return 301 lines here. Then delete the lines covering your certificate files. Once done, restart nginx with service nginx restart

Ex. You’ll want to remove the lines that look like this:

        ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

as well as making sure you don’t leave anything referring to port 443. Your default-ssl.conf file will not be changed in any way, we’ll just use it as a source for the configuration directives we need.