Resolved Plesk 18.0.20 but no TLS 1.3?

[G J Piper]

My server is updated to the latest Plesk Obsidian 18.0.20, and the settings appear to have TLS 1.3 enabled, but for some reason all remote tests say that my server does not support TLS 1.3.

Any Ideas why? See my signature for versions.

# nginx -V 2>&1 | head -n3
nginx version: nginx/1.16.1
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled

# plesk bin server_pref -s | grep ssl
ssl-protocols:   TLSv1 TLSv1.1 TLSv1.2 TLSv1.3
ssl-ciphers:   EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH
ssl-cipher-server-order:   true

 

[Brujo]

it seems to depends on the OS, see Can TLS 1.3 be enabled in Plesk?

 

[G J Piper]

it seems to depends on the OS, see Can TLS 1.3 be enabled in Plesk?

So even though nginx is specifically "built with OpenSSL 1.1.1d" the OS has to also be Ubuntu 18.04?

The phrase they use, "At the moment, only Ubuntu 18.04, by default, has an OpenSSL version 1.1.1 which is required for TLSv1.3" is somewhat ambiguous... It could mean that only the OpenSSL that is "default" for your OS has to be at least v1.1.1, or it could mean that the OS must be Ubuntu 18.0.4 also.

I guess since my "default" OpenSSL for CentOS 7.7 seems to be this:

# openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

Then I will never be able to use TLS 1.3?

 

[learning_curve]

@G J Piper There's a little bit of history with this one. The Plesk page that @Brujo has posted the link to, has recently been corrected. We started a different thread about the 'absence' of TLSv1.3 in an Obsidian Preview release, when it was already active in Onyx 17.8.11 although, this thread was specifically in relation to the Plesk sw-cp-server and Ubuntu 18.04 LTS OS.

The thread is HERE. In post #5 we asked questions about the content of that ^^ Plesk Page and in post #6 you'll see it was posted that the Plesk page would be re-worked / corrected, which it subsequently was. To be fair, in the re-worked verison, it's clearer now that the sw-cp-server, is the area where TLSv1.3 limitations remain, not any customers’ websites that are served by nginx and accessed by HTTPS. The Obsidian GA release is different (and much better) than the Preview release was so we did acknowledge that too in THIS later thread.

Speculating a little really, but to try and answer your post, in Obsidian, as we understand it now, unless you customise things yourself (as has been done on previous Plesk releases e.g. THIS thread) then your OS must run a minimum OpenSSL version v1.1.1 AND... Plesk must also officially support TLSv1.3 for their own sw-cp-server when running on that OS, IF, you want comprehensive TLSv1.3 serverwide coverage (i.e. Both public & Plesk admin areas). Official support for running TLSv1.3 on CentOS 8 / Debian Buster & other later OS releases should be arriving in due course, so in theory just like Ubuntu 18.04 LTS was (as of the Obsidian GA release onwards >>>) it should be... comprehensive TLSv1.3 serverwide coverage too, for all of those OS releases. As you've stated though, it appears (somebody from Plesk might confirm for definite?) that OS releases which don't run OpenSSL version v1.1.1 by default, may indeed, probably never be able to run TLSv1.3 on their sw-cp-server unless, they have been suitably customised (by their own server admin) outside of Plesk.

 

[G J Piper]

@learning curve
Thanks for your commentary on this. I'll read through the other threads.
I'm really only concerned with getting the public-side hosted websites supporting 1.3.
If I'm missing something to get those reading as "supported" at SSL Labs it eludes me.

 

[learning_curve]

I'm really only concerned with getting the public-side hosted websites supporting 1.3. If I'm missing something to get those reading as "supported" at SSL Labs it eludes me

Assuming that you've specified specific TLSv1.3 ciphers correctly (it looks that way, but you've provided details of all your ciphers above, in a different format method than we use, plus you have many more anyway because we only support TLSv1.2 and TLSv1.3) Have posted the same command you ran just for your reference below;

# plesk bin server_pref -s | grep ssl
ssl-protocols:    TLSv1.2 TLSv1.3
ssl-ciphers:    TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-cipher-server-order:    true

As you probably know already, the Mozilla GUIDE makes the TLSv1.3 bit pretty easy to follow. However, the other assumption is, that you're using Nginx as part of the access route to the websites that you're testing this on (i.e. they are not just Apache only), then yes, agreed, "...the public-side hosted websites supporting 1.3..." should support TLSv1.3 by default when using Obsidian, hence your question!

 

[G J Piper]

the other assumption is, that you're using Nginx as part of the access route to the websites that you're testing this on (i.e. they are not just Apache only)
hence your question!

That is correct. Nginx is my reverse-proxy with Apache running as FastCGI serving websites.

Here is an SSL-Labs report: SSL Server Test: piperhosting.net (Powered by Qualys SSL Labs)

 

[learning_curve]

Here is an SSL-Labs report: SSL Server Test: piperhosting.net (Powered by Qualys SSL Labs)

We're a bit more private on posting domain urls, but the two images below are from a domain that we host and that we have just run the same Qualys Test on for illustration here. Knee jerk reaction is: No specifc TLSv1.3 ciphers appear to be specified in your case? What say you?

 

[G J Piper]

I think I found the problem. For some reason this was the output I found:

#cat /etc/nginx/conf.d/ssl.conf
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

I added TLSv1.3 to the end of the ssl_protocols and it now works! Thanks for helping me find the problem. Apparently Obsidian hadn't changed that code because I had once modified it manually before.

 

[learning_curve]

@G J Piper We didn't help you really It was just a bit of luck that what we posted, meant that you re-checked why the ciphers were missing, which you then tracked down yourself, to incorrect content inside the infamous /etc/nginx/conf.d/ssl.conf file which... hadn't been posted here in this thread prior to that, so neither of us saw it!

Really glad that's it's solved now though

Maybe of some use (not to you now obviously, but to other thread readers) but THIS Plesk page, if you add the TLSv1.3 protocol to it, especially the 'via command line interface' section, is a handy way of pre-empting the situation that you found

 

[G J Piper]

Just figured something out. The new SSL It extension removes the TLSv1.3 from my server settings when the "TLS versions and ciphers by Mozilla" is enabled and syncs. Mozilla's at fault!?

 

[learning_curve]

Wow! We never used the SSL It extention in Onyx anyway, but it is installed by default for Obsidian, although it can easily be disabled or removed like all Plesk extentions. It's had quite a few bugs, so has been upgraded a few times now, but we have practically all of its functions switched off (including the "TLS versions and ciphers by Mozilla" one) so can't add any reference data to your findings sorry. We still prefer to apply many of the SSL It settings manually in Plesk but outside of the extention.

 

[G J Piper]

Wow! We never used the SSL It extention in Onyx anyway, but it is installed by default for Obsidian, although it can easily be disabled or removed like all Plesk extentions. It's had quite a few bugs, so has been upgraded a few times now, but we have practically all of its functions switched off (including the "TLS versions and ciphers by Mozilla" one) so can't add any reference data to your findings sorry. We still prefer to apply many of the SSL It settings manually in Plesk but outside of the extention.

I used to do absolutely everything 100% manually. IE: no GUI at all, not even Plesk. An ISP guy finally convinced me to try Plesk, as it "does everything you do but with 1/10 of the hassle" and I've never looked back. However, now I'm beginning to glance back every so often lol.

 

[Spirogg]

hi, just following your thread , so if we manually add TLSv1.3 as you suggested, even after enabling TLS versions and ciphers by Mozilla" is enabled and syncs will it stay enabled or be removed ?

I added TLSv1.3 to the end of the ssl_protocols and it now works!

Just figured something out. The new SSL It extension removes the TLSv1.3 from my server settings when the "TLS versions and ciphers by Mozilla" is enabled and syncs. Mozilla's at fault!?

 

[themew]

I think I found the problem. For some reason this was the output I found:

#cat /etc/nginx/conf.d/ssl.conf
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

I added TLSv1.3 to the end of the ssl_protocols and it now works! Thanks for helping me find the problem. Apparently Obsidian hadn't changed that code because I had once modified it manually before.

Your signature displays you're using CentOS 7.7.1908 and Apache 2.4.6. We you able to activate TLS 1.3 adding the ciphers to your NGINX config on this server? If so, it's a great reason to upgrade to Plesk Obsidian now rather than later...

 

[G J Piper]

hi, just following your thread , so if we manually add TLSv1.3 as you suggested, even after enabling TLS versions and ciphers by Mozilla" is enabled and syncs will it stay enabled or be removed ?

If you manually add TLSv1.3 it gets removed every time the "TLS versions and ciphers by Mozilla" is enabled or synced. I copied the ssl_ciphers and manually added them too and shut off the "TLS versions and ciphers by Mozilla" checkbox.

 

[G J Piper]

Your signature displays you're using CentOS 7.7.1908 and Apache 2.4.6. We you able to activate TLS 1.3 adding the ciphers to your NGINX config on this server? If so, it's a great reason to upgrade to Plesk Obsidian now rather than later...

I believe this entire thread is "Plesk Obsidian for Linux". We should all implicitly be talking about Plesk Obsidian here, as my signature lists. Yes, my server is working correctly and serving with TLSv1.3 now but I just need to leave "TLS versions and ciphers by Mozilla" turned off.

 

[learning_curve]

Y....We you able to activate TLS 1.3 adding the ciphers to your NGINX config on this server? If so, it's a great reason to upgrade to Plesk Obsidian now rather than later...

We let @G J Piper answer that ^^ question, because it's his thread & you asked him to be fair, but yes, Obsidian is a much welcomed step forward from Plesk @themew especially for anybody running an older release server OS

The only TLSv1.3 caveat for Obsidian is, that on this Plesk page: Can TLS 1.3 be enabled in Plesk? the answer is very specific: "...TLSv1.3 support was implemented in the Plesk Obsidian 18.0 version for customers’ websites that are served by nginx and accessed by HTTPS..." That's why we asked @G J Piper the question in post #5 / which was answered in post #6 (this thread) because at that stage in the thread, a possible "Apache only" status, wasn't 100% clear to us, but that question is irrelevant anyway now, as "Apache only" sites were not the cause of the issue in this case.

FWIW If we've understood things correctly, if you run an older release server OS, that doesn't have OpenSSL 1.1.1. and, that doesn't have an up-to-date or backported version of Apache and, that has sites on it that are not served by Nginx at all (i.e. Apache only) then they couldn't support TLSv1.3, because there's no method of providing the required data to support it. This is true even if using Obsidian, because the Plesk customised Nginx package in Obsidian is what compensates for the other shortfalls, but if that nginx service is not required, then.... No idea how many instances of non-nginx setups there are and we're only guessing, but it can't be that many that they then become a big reason not to upgrade Obsidian.

 

[G J Piper]

I suppose this entire thread can be summed up with this:

1. Yes I should have TLS 1.3 working on my public-facing server — it meets the requirements and has Plesk Obsidian.
2. SSL It extension is responsible for keeping it from working when "TLS versions and ciphers by Mozilla" is turned on at any level.

Workaround Solution: Turn off "TLS versions and ciphers by Mozilla" and make sure your settings are correct, manually.