• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Use TLS1.2 only and remove specific ciphers...

learning_curve

Golden Pleskian
We have run the excellent: plesk pci_compliance_resolver and that takes us pretty close already (i.e. only TLS 1.1 & 1.2) but we can't see another straightforward way, to take this one step further and use TLS1.2 only on all domains.

There are four (!) different ssl.conf files on our cloud server:

1) ./etc/httpd/conf.d/ssl.conf
2) ./etc/nginx/conf.d/ssl.conf
3) /etc/sw-cp-server/conf.d/ssl.conf
4) ./etc/proftpd.d/ssl.conf

So editing the correct file via command line would just be guessing and a bit of good luck for us currently...
Does anybody have a structured method / easy to follow data path / instructions to achieve this?

Once that's done :) Even after running plesk pci_compliance_resolver, these four, existing ciphers, we still wish to specifically remove. A guess, but we think that these won't be removed even if/when we achieve TLS1.2 only status:

TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

Again, does anybody have a structured method / easy to follow data path / instructions to achieve this too? Thanks!
 
Thanks UFHH01, that's very, very helpful for us.

As per our initial post, we have already read and run the actions detailed on your 1st link: => Tune Plesk to Meet PCI DSS on Linux And we forgot to say (sorry!) but we are already HTTP/2 enabled as per your 2nd link: => HTTP/2 Support in Plesk Both of these are great references for anybody else requiring the same status as we do.

Your other two very useful references:

The "sslmng" utility has several options, which you are as well able to list with the command:
Code: plesk sbin sslmng --help

Pls. see my previous eamples here: => #2 ( and note the difference usage ' instead of " )


Yes, we're pretty sure these are exactly what we were looking for.
We'll slowly and carefully ;) work through these and confirm shortly.
 
Well.... nothing is ever straightforward :)

We ran actions in this order:

Resolved - How can I adjust HSTS in Plesk?
This worked perfectly with no problems.

So then we switched to the other changes and ran:
plesk sbin sslmng --services=nginx --custom --ciphers='ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
This also worked perfectly with no problems, followed by:
plesk sbin sslmng --services=nginx --custom --protocols=‘TLSv1.2'
This also worked perfectly with no problems

However, Apache is where is goes wrong...
When we run this in SSH, this command just produces > and the shell window functions no further....
plesk sbin sslmng --services=apache --custom --ciphers='ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; --protocols=‘All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1’
This is exactly the same:
plesk sbin sslmng --services=apache --custom --protocols=‘All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1’
If we run post action checks (these are all on live sites) Qualys SSL Labs gives the desired result in the report i.e. TLSv1.2 only and quite happy with those ciphers, but obviously this is NGINX only, as it's proxy in front of Apache.

So it's obvioulsy not finished yet and we don't understand why the Apache commands won't run? Or why they just give a > via SSH and there are no changes at all to /etc/httpd/conf.d/ssl.conf

If we then look at /etc/nginx/conf.d/ssl.conf the content (see below) appears to show that TLSv1.1 is still active but it isn't, as we can clearly see via Qualys SSL Labs report so that's a bit :confused:
<snip>
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
<snip>

Most likely we have made a keying / input error?
If you have another moment UFHH01 we'd be happy to take some more advice!

Finally, once we've solved this, does this Plesk warning:
Note: The changes made by the sslmng utility can be overwritten by the subsequent call of the server_pref utility or by a Plesk update.
actually mean that we'll need to run these customisation actions after each Plesk system update, including microupdates? That's worth us knowing in advance :)
 
Hi learning_curve,

to investigate possible additional configurations, you might like the idea to use a "find" - command:

For Debian/Ubuntu - based systems:
Code:
find /etc/apache2 -type f -name "*.conf" -exec grep --color -Hni "ssl_protocols" {} \;
and
Code:
find /etc/apache2 -type f -name "*.conf" -exec grep --color -Hni "ciphers" {} \;

For CentOS/RHEL - based systems:
Code:
find /etc/httpd -type f -name "*.conf" -exec grep --color -Hni "ssl_protocols" {} \;
and
Code:
find /etc/httpd -type f -name "*.conf" -exec grep --color -Hni "ciphers" {} \;

For ALL - linux - systems, there are as well domain - specific configuration files, where you could as well find depending configurations with for example:
Code:
find /var/www/vhosts/system -type f -name "*.conf" -exec grep --color -Hni "ssl_protocols" {} \;
and
Code:
find /var/www/vhosts/system -type f -name "*.conf" -exec grep --color -Hni "ciphers" {} \;

... so that you are able to investigate, if one or the other configuration overwrites a previous one. ;)



Pls. don't forget, that the command:
Code:
plesk repair web -y -v
... is able to rebuild ALL configuration files. ;)

Pls. inform yourself about the Plesk Repair Utility ( and it's possible options ) at:

=> Plesk Repair Utility



In addition, you have as well the choice to change your server - preferences with the Plesk - CLI - commands:
Code:
plesk bin server_pref -u -ssl-ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'
AND
Code:
plesk bin server_pref -u -ssl-protocols 'TLSv1.2'

Pls. inform yourself about MORE possible Plesk - CLI - commands ( and their options! ) at:

=> Command Line Utilities Overview
 
Okay. Update:

CentOS/RHEL - based system
find /etc/httpd -type f -name "*.conf" -exec grep --color -Hni "ssl_protocols" {} \;
Running this we receive a zero response. Nothing at all.
find /etc/httpd -type f -name "*.conf" -exec grep --color -Hni "ciphers" {} \;
Running this we receive this response:
/etc/httpd/conf.d/ssl.conf:78:## List the ciphers that the client is permitted to negotiate.
/etc/httpd/conf.d/ssl.conf:80:#SSLCipherSuite HIGH:!aNULL:!MD5
/etc/httpd/conf.d/ssl.conf:81:SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
/etc/httpd/conf.d/ssl.conf:85:## optimized ciphers. In this case, prepend those ciphers
/etc/httpd/conf.d/ssl.conf:86:## to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
/etc/httpd/conf.d/ssl.conf:92:##SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
/etc/httpd/conf.d/ssl.conf:106:## both in parallel (to also allow the use of DSA ciphers, etc.)
/etc/httpd/conf.d/ssl.conf:222:#SSLCipherSuite EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EDH+AESGCM+AES128:EDH+AESGCM+AES256: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:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES
Sorry about the Emojis, that's down to : and D being next to each other in the code and the emoji replaces them...
 
Both of these run fine and update all other instances of ssl.conf:
...you have as well the choice to change your server - preferences with the Plesk - CLI - commands:

plesk bin server_pref -u -ssl-ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'

AND

plesk bin server_pref -u -ssl-protocols 'TLSv1.2'

We looked again at the updated /etc/nginx/conf.d/ssl.conf out of interest and the content (see below) is still unchanged (showing that TLSv1.1 is still active, but it isn't. This is presumably only because it's now an authority level lower than the server_pref changes above?
<snip>
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
<snip>
 
Ahhhhhh That's our error for sure :D
We assumed that this was post plesk_repair (i.e. only needed if there were faults that the main
plesk_repair all
initially would or could not resolve...)
So we've back tracked, added this in and re-done everything now.
The very latest /etc/nginx/conf.d/ssl.conf still says this:
says: <snip>
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
<snip>
But... it's all good.
The end results are configured correctly, it reports correctly for end users and it all works: Dropbox - Plesk.png
So this small oddity we're not going to worry too much over now!
Thank you! Resolved we'd say?
 
Hi learning_curve,

The very latest /etc/nginx/conf.d/ssl.conf still says this:
Code:
says: <snip>
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
<snip>
But... it's all good.
Well, "normally" the command:
Code:
plesk sbin sslmng --services=nginx --custom --ciphers='YOUR-DESIRED-CIPHER-LIST' --protocols='YOUR-DESIRED-PROTOCOL(s)'
... should write exactly what you desired into "/etc/nginx/conf.d/ssl.conf". If you experience issues/errors/problems here, you should investigate your "panel.log" ( /var/log/plesk ).

Sometimes, it is as well a good idea to change the log - level ( TEMPORARILY! ), to get more informations in Plesk - log - files:

 
Thank you!
you should investigate your "panel.log" ( /var/log/plesk )
We have done this now, but there are no entries at all in this log relating to what we have covered in this thread.

In order to try and understand the 'limitation', we ran ONLY this code via SSH to 'update' the protocol content of the very latest /etc/nginx/conf.d/ssl.conf. This should have updated /etc/nginx/conf.d/ssl.conf we think?
Code:
plesk sbin sslmng --services=nginx --custom --protocols=‘TLSv1.2'
The returned value is again just this (which then requires a new shell window and nothing is changed)
Code:
>
The ciphers are already 100% correct in the very latest /etc/nginx/conf.d/ssl.conf (which was generated yesterday as part of server_pref when we were following your earlier post)

To summarise:

After running server_pref ^^ All these files are updated.

1) ./etc/httpd/conf.d/ssl.conf
2) ./etc/nginx/conf.d/ssl.conf
3) /etc/sw-cp-server/conf.d/ssl.conf
4) ./etc/proftpd.d/ssl.conf

The ciphers AND protocols are correct in 1) 3) and 4)
The ciphers are correct in 2) The protocols are not. TLSv1.1 is still retained in the code.
Everything (at an end user level runs perfectly and 100% correctly using these ciphers and always at TLSv1.2 only

Can this file: ./etc/nginx/conf.d/ssl.conf simply be manually amended vis SFTP / SSH and then nginx restarted?
That's our final though for a complete resolution for us? o_O The main issue is already resolved.
 
Last edited:
Hi learning_curve,

Can this file: ./etc/nginx/conf.d/ssl.conf simply be manually amended vis SFTP / SSH and then nginx restarted?
Not the recommended way, but since your investigation and descriptions are very clear and don't point to any missing process, pls. don't hesitate to manual edit the file. ( Could as well be a tiny bug, which might be reported at: => Home > Forum > Plesk Discussion > Reports )

That's our final though for a complete resolution for us?
jap... I agree.
 
@learning_curve ,

i have tried your Cipher - its good, except for HIPAA support (requires TLSv1.1) which i have already left active.
But seems not working.

Here the nginx Conf:

Code:
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_stapling on;

My two Problems: HIPAA not working and Stapling allegedly is not turned on.
But i have it in Nginx :-/

Any recommendations?
 
My two Problems: HIPAA not working and Stapling allegedly is not turned on. But i have it in Nginx :-/ Any recommendations?
:) This is an old thread now. There's been quite a lot of Plesk updates since then and we've also changed quite a lot of things since this was a current thread too. Still, with regard to your current questions...

The HIPAA and NIST requirements for TLSv1.1 are pointless and possibly outdated now we think? Many online payment processes / API's / other softtware are all TLSv1.2 only now which is why we ditched TLSv1.1 some time ago. We did switch to TLSv1.2 AND TLSv1.3 for a while, but it was at draft stage only, so we revoked that and are currently back to TLSv1.2 only, but patiently waiting for TLSv1.3 to be formally released at which point, we will modify eveything again. Independent tests on both HIPAA and NIST work perfectly for us, but also carry the messages: Non-compliant with HIPAA guidance / Non-compliant with NIST guidelines The operative words being guidance / guidelines ;) Hence we just ignore them for all the reasons mentioned

An example /etc/nginx/conf.d/ssl.conf file is:
Code:
# SSL Sessions
ssl_session_cache shared:SSL:50m;
# ssl_session_timeout  10m;

#SSL ECDH Curve
ssl_ecdh_curve X25519:P-521:P-384:P-256;
              
# SSL Protocol
ssl_protocols TLSv1.2;

#SSL DHParam
ssl_dhparam /etc/dhparam/dhparam.pem;

# SSL Ciphers
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

For simple domains, with simple SSL Certs, we found the eaisiest way was not adding OCSP Stapling in the nginx conf, but to add it via the Plesk GUI Panel > Apache & nginx settings for MyDomain.com > Additional nginx directives where you can add:
Code:
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
Depends on how many domains you have and you may prefer DNS other than Google. It's slightly different code for more complicated domains / SSL Certificates, but the same location / process can be used if you want to do it this way.
 
Back
Top