Turning NGINX on breaks SSL Chain

[M. Piazza]

I can confirm that this issue has seemingly re-appeared again after the latest 11.5 update. I had Plesk Panel 11.0.9 before and never ran into this specific issue, but have noticed however that after the 11.5 major update, with all the new NGINX features etc., this problem for me has re-emerged but "ONLY" does this with older IE8, and also Safari web browser (Firefox, Chrome, and Opera are still just fine).

What's happening here is that after the Parallels Plesk Panel 11.5 update now, with 'NGINX' enabled it will throw SSL errors but to only specific browsers (in my case to IE8 and the latest Safari -- I haven't tested it on IE9 or IE10 yet however, but will soon, just to see), but if I were to simply Disable NGINX from the Plesk panel there, 'voila', the SSL error issue is completely gone, no certificate warnings or anything (and as it's just simply via Apache now).




..... The Warning/Errors are that it's trying to load the basic native backend "Parallels Panel" cert for only certain web browsers:


" Certificate Information

This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store.

------------------------------

Issued to: Parallels Panel

Issued by: Parallels Panel

Valid from 4/11/2013 to 4/11/2014 "

------------------------------



....So yep, definitely something with NGINX via the Plesk Panel specifically here, and seemingly "ONLY" after the 11.5 update that I had recently done, this specific error came back only after the update

..[UPDATE] ......Also I should actually note guys, that this only happens within certain browsers "AND" certain actual operating systems. For example this SSL error doesn't even happen when using Windows 8 w/Safari web browser. but however "DOES" mysteriously error when using Windows 'XP' w/same version of Safari web browser. ....Perhaps a DNI bug/issue? ....I'm not sure, all I know is that this wasn't happening before the 11.5.0 Plesk Panel update, my 11.0.9 seemed to be flawless with everything

-MP

 

[websavers]

I also have encountered this problem with Plesk Panel 11.5.30 Update #5 (July 15, 2013). The problem is that the CA Certificate is not loaded in nginx. For many certificates this isn't a problem because the root certs and intermediaries that are required are built in to your OS or Browser, but in the wrong configurations it can still fail (such as certain Comodo SSL Certs using Firefox on Ubuntu). I was able to verify the broken chain using this SSL Checker Tool: http://www.sslshopper.com/ssl-checker.html

In checking the domain's configuration files, I found the following line:

ssl_client_certificate /usr/local/psa/var/certificates/[CERT-FILENAME];

But for this to work properly it should be:

ssl_trusted_certificate /usr/local/psa/var/certificates/[CERT-FILENAME];

I've duplicated it to have both and once ssl_trusted_certificate has been added, the SSL checker tool linked above reports a working chain of trust. It looks like Plesk should be writing domain configuration files with ssl_trusted_certificate along with the ssl_client_certificate for the CA Certificate value.

---

What's odd about this is that the NGINX documentation says the following in reference to the ssl_trusted_certificate configuration parameter:

"In contrast to ssl_client_certificate, the list of these certificates will not be sent to clients."

One would think that means ssl_client_certificate is the correct parameter to use, but clearly in practice this isn't the case. Perhaps an nginx bug? Even if it is, if Plesk simply sets both of these parameters in the domain's configuration file to the same value, it should work now and for future versions of nginx.

 

[BlueChannel]

We recently upgraded a live server from Plesk 11.0.9 Update #55 to 11.5.30 Update 7. We had the issue of the default server certificate loading in some browsers for all sites with SSL enabled. Ultimately, we solved this by disabling SNI and then associating each IP address with the proper client certificate in the IP settings area. Hopefully this helps someone, as it took us a long time to figure this out. Plesk support wasn't helpful, and instead offered a solution that was not at all appropriate.

 

[TSCADFX]

I have another post going about many issues that I've encountered with nginx, plesk and ssl certs. Here's the link to that post: http://forum.parallels.com/showthread.php?289546-NGINX-SSL-needs-to-be-fixed

If you make the changes in #1 and then reconfigure the domains and apply the certificate chain fix as described in #6 that should fix all of the issues on the domains with SSL certificates. Granted this will fix all active domains but once the panel is updated the php files will most likely be overwritten and the issue will persist for any domains that are newly created post update unless the changes are re-applied.

Just FYI the default certificate loading issue is also addressed in my post, specifically #4. What's happening is that nginx follows a path from /etc/nginx/nginx.conf -->> /etc/nginx/conf.d/zz010_psa_nginx.conf -->> /etc/nginx/plesk.conf.d/webmail.conf -->> /etc/nginx/plesk.conf.d/vhosts/domain.tld.conf. The webmail.conf is using the default cert with the server_name directive telling it to only apply the panel cert to the mail.* domains listed, etc. For some reason this is broken and the cert is being applied to anything. It essentially ignores the domain.tld.conf file completely. Of course you could always take the client certificate and install it in the control panel and assign it to the ip address, which should fix the issue should the client be assigned to a dedicated ip. If the client is on a shared IP then the issues need to be fixed using the steps outlined in the post.

 

[Nikolay.]

Granted this will fix all active domains but once the panel is updated the php files will most likely be overwritten and the issue will persist for any domains that are newly created post update unless the changes are re-applied.

Technically one should use custom vhost templates for that (templates/custom). That way changes will not be lost on Panel upgrade/update. However they are also prone to causing issues (reconfiguration failures) on upgrade if default templates changed a lot.

 

[onlinesolutions]

The 2 main reasons why I upgraded to 11.5 from 10.4:

- encrypted backup
- nginx

Both features are not working at all. Backup stalls whenever it hits a file that is owned by apache. I spent one day trying to locate the error with the ssl certificate and even bought a new one, as I thought it is broken. To be franc, I am not prepared to apply some workarounds for a software I am paying money for. Free software works better.

When are these issues being fixed?

 

[TSCADFX]

I have successfully made SSL certs work with nginx and Plesk, but yes it does require the work around. In addition, if you are using a SSL certificate with domain.tld and not www.domain.tld it will fail on many browsers that don't support SNI due to nginx. To be fair this is a limitation with nginx and not Plesk. The options are to purchase a much more expensive SSL certificate that will accept any subdomains or redirect all traffic from domain.tld to www.domain.tld.

Trust that we too are pulling our hair out!

 

[onlinesolutions]

Hi Tscadfx,

Thanks a lot for your work! Excellent. As we are paying for the software we would expect though that this will be taken care ASAP including the botched backup routine. Companies of that size and scope should hire a quality assurance team. It appears that they are leaving this up to the community.

 

[onlinesolutions]

The backup routine seems to be fixed now. Great. Does anyone know if the SSL issue with nginx is fixed too?

 

[websavers]

The backup routine seems to be fixed now. Great. Does anyone know if the SSL issue with nginx is fixed too?

This is not yet repaired as of 11.5.30 Update #10 (and update #11 is just a single unrelated fix). However, I do have a more 'permanent' work around. For the domain where the chain of trust cannot be established, in Plesk, go to "Web Server Settings" and scroll down to "Additional nginx directives". In that box you can enter the line I've described above:

ssl_trusted_certificate /usr/local/psa/var/certificates/{your-cert-filename};

Because this writes to the vhost-specific config file, updated configuration files will not be affected by the change. You'll need to find the cert file name by opening the config in the back-end still:

/var/www/vhosts/system/{domain}/conf/last_nginx.conf

 

[TSCADFX]

The backup routine seems to be fixed now. Great. Does anyone know if the SSL issue with nginx is fixed too?

No it is not fixed yet and I haven't seen any official response from Parallels regarding it either.

However, I do have a more 'permanent' work around. For the domain where the chain of trust cannot be established, in Plesk, go to "Web Server Settings" and scroll down to "Additional nginx directives". In that box you can enter the line I've described above:

I wouldn't recommend this because it still doesn't resolve the PCI compliance issues. If you're going to install a certificate with server vulnerabilities then what's the point of having one to begin with? Additionally, if you have multiple clients going through and placing additional nginx directives in all of your client's configurations will take forever.

A better fix would be to put the 2 files that I included by clicking here into /usr/local/psa/admin/conf/templates/

It resolves the PCI compliance issues and a simple reconfigure all domains should apply the changes all around.

 

[onlinesolutions]

Thanks to both of you. I am sure the community appreciates it. I can testify though that websavers solution works. I checked the certs and there is no issue now. TSCADFX why there are still PCI compliance issues?

 

[TSCADFX]

The reason his solution works is because it adds the trusted cert which is missing from the configuration. The problem with this approach is multifaceted.

1 - When, and if, Parallels decides to add the trusted cert to the config your server will fail to initialize nginx, which could be in the middle of the night during an upgrade. The nginx test will fail because of duplicate entries. If you have multiple web spaces that are modified in this manner you'll surely have a hand full

2 - The ciphers used by default are not PCI compliant and are insecure. In addition, SSLv2 is allowed. Test your domain here and you'll see that it will fail PCI compliance.

3 - Attempting to make the proper changes through the additional nginx directives to make the site PCI compliant is impossible because of the duplicate directives. Therefore the actual .conf file needs to be modified.

The fix: The files that I provided are configuration files that go in the custom folder. When Plesk configures the domain it references the custom folder first and uses those files if they exist over the default Plesk ones. This allows for admins to make custom changes on a larger scale. When, and if, Parallels does make this correction simply remove the custom file, reconfigure the domains and all clients will automatically be swapped over to the default again.

The following line is added in the configuration files that I provided:

ssl_trusted_certificate      <?php echo $sslCertificate->caFilePath ?>;

And the PCI compliance change is:

    ssl_protocols               SSLv3 TLSv1;
    ssl_ciphers                  RC4:HIGH:!MD5:!aNULL:!DH:!EDH;
    ssl_prefer_server_ciphers   on;

The files that I provided also eliminate the use of SSLv2 and only provide high grade ciphers.

 

[onlinesolutions]

Thanks TSCADFX. Great explanation. Great work.

 

[websavers]

Looks like this is finally fixed in 11.5.30 Update #14 [09-Sep-2013]:

"[-] Panel did not concatenate chained certificates bundles provided by Geotrust to the main certificate in the nginx configuration."

 

[onlinesolutions]

I just don't see which files have been modified to alleviate the issue. The file that should have been modified still has the same time stamp on our server. Strange.

 

[PriyanA]

11.5.30 Update #20

I had a similar issue.

Installed COMODO SSL to a website.

Internet Explorer 10 and Chrome 30.0 didn't have any problem but Firebox 24.0 was giving Untrusted Certificate warning.

Checked with http://www.sslshopper.com/ssl-checker.html was showing Broken Chain Problem.

Stopped and Started nginx Fixed the Problem.