• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved Nginx magic

mr-wolf

Silver Pleskian
Plesk Guru
I am using nginx to host a multi-domain PHP provisioning script on several servers.
I have that working and it seems to have no impact on the other websites on that server.

All except 1.

On 1 server I have a website running that has "Permanent SEO-safe 301 redirect from HTTP to HTTPS "
This is a security feature that prohibits subsequent http connections to prevent a man-in-the-middle attack.

When my nginx config is enabled it is suddenly not possible anymore to connect with http using a new browser. No redirection takes place anymore.

[EDIT]
I have tested it again just now and noticed that the entries in the "/nginx/autodiscover/error.log" are not made when trying to do a normal http connection to that site. It's just that redirection doesn't take place and I'm getting a blank page.
I can only test it once. I think I first need to find out how to get rid of this permanent redirect of the browser.

The website is working fine using https.
Because of that I was unable to see the problems that started occuring.
This only happened to new users.

Someone in this forum placed this link https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ and it seems my script can be improved, although I don't know how.

I have disabled the config on that server for the time being.
I have this in my /var/log/nginx/autoconfig_autodiscover/error.log
Code:
2017/03/20 14:06:06 [error] 918#0: *15 no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: 89.250.187.42, server: xx.xxx.xxx.xxx:80

There are no ssl entries in the port 80 section because normally it doesn't connect with ssl there.
Does this mean that the "redirect HTTP to HTTPS" means that it will keep connecting to port 80?

The site that has a problem doesn't match "server_name ~^autoconfig\.[a-z0-9-]+\.[a-z0-9-]+$;"
Should I still give my certificates there?
The certificates I can give there don't match the site to which the browser wants to connect.
So if I give the same certificates as in the 443-connection there will still be some problem.

Can anyone help me out regarding this config?
BTW... it is running fine for the autodiscover itself.

cat /etc/nginx/conf.d/zz095_autodiscover.conf.backup
Code:
server {
    listen xx.xxx.xxx.xxx:80;
    server_name ~^autoconfig\.[a-z0-9-]+\.[a-z0-9-]+$;

    root  /var/www/autoconfig_autodiscover;

    index index.html;
    error_log /var/log/nginx/autoconfig_autodiscover/error.log;
    access_log /var/log/nginx/autoconfig_autodiscover/access.log combined;

    location /mail/config-v1.1.xml {
      try_files $uri /config-v1.1.xml.php?$args;
      rewrite ^(.+)$ /config-v1.1.xml.php?$1 last;
    }


   location ~ config-v1\.1\.xml\.php$ {
     try_files $uri =404;
     include /etc/nginx/fastcgi_params;
     fastcgi_pass 127.0.0.1:9000;
     fastcgi_index index.php;
     fastcgi_param SERVER_FQDN  $host;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param PATH_INFO $fastcgi_script_name;
     fastcgi_intercept_errors on;
   }
}


server {
    listen xx.xxx.xxx.xxx ssl;
    server_name ~^[a-z0-9-]+-[a-z0-9-]+\.providerdomain$;
    root  /var/www/autoconfig_autodiscover;

    error_log /var/log/nginx/autoconfig_autodiscover/error.log;
    access_log /var/log/nginx/autoconfig_autodiscover/access.log combined;

    ssl_certificate             /root/.ssh/wildcard.pem;
    ssl_certificate_key         /root/.ssh/wildcard.key;

    ssl_stapling on;
    ssl_stapling_verify on;

    ssl_session_timeout         5m;

    # ssl_protocols               SSLv2 SSLv3 TLSv1;
    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers                 HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers   on;
    ssl_dhparam /etc/ssl/private/dhparams.pem;

    client_max_body_size 1m;

    index index.php index.html index.htm;

    location /autodiscover/autodiscover.xml {
      try_files $uri /autodiscover.xml.php?$args;
      rewrite ^(.+)$ /autodiscover.xml.php?$1 last;
    }

   location ~ autodiscover\.xml\.php$ {
     try_files $uri =404;
     include /etc/nginx/fastcgi_params;
     fastcgi_pass unix:/run/php/php7.0-fpm.sock;
     fastcgi_index index.php;
     fastcgi_param SERVER_FQDN  $host;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param PATH_INFO $fastcgi_script_name;
     fastcgi_intercept_errors on;
    }
}
 
Last edited:
I did some more tests and it was the 2nd part, not the first.
Then I looked more closely and noticed that the ":443" was gone...

So it wasn't magic.. just a botched config...

It was only a problem with this server because I removed the :443 by accident when I changed the IP after copying it from another server.
 
Back
Top