Resolved Issue applying SSL Ciphers

Tyson_Moore · Mar 3, 2021

So were are using POLipay as one of our payment gateways on WHMCS.

We moved our company site from a cPanel Server in Australia to our own Plesk Server in New Zealand.

We had an old POLipay plugin that appeared to stop working, so we updated to a new one from a company in Australia. It goes through the whole process, except the "Nudge" back. So the payment is made, but the invoice isn't marked as paid.

The below SSL Ciphers are needed (API Functions | Developer Wiki):
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(P384) - ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(P256, P384) - ECDHE-ECDSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - DHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - DHE-RSA-AES128-GCM-SHA256

I have used this site to get the correct format:

openssl ciphers -- SSL cipher display and cipher list tool

Yet going through SSL Labs test doesn't seem to come up with them no matter what I do.

I have tried manually editing the files below and restarting both Litespeed and Plesk's own web server:
/etc/httpd/conf.d/ssl.conf
/etc/sw-cp-server/conf.d/ssl.conf

I have used the SSL It! Configuration and set to "Intermediate" as that was meant to have supported at least one of the needed Ciphers, and still no luck. I even tried turning off this functionality and setting them manually.

I have also tried "plesk bin server_pref -u -ssl-ciphers" which again set them in the config files, but still doesn't appear on the SSL Labs test.

I've read through a lot of the forums I could find (including the thread here). Can't think of what else to try, other than go through each process for about a 10th time.

Any new ideas would be greatly appreciated.

learning_curve · Mar 3, 2021

Tyson_Moore said:
>>>> I've read through a lot of the forums I could find (including the thread here). Can't think of what else to try, other than go through each process for about a 10th time<<<<

@Tyson_Moore You've not mentioned nginx, so you're probably not using it at all?

You can set all ciphers manually, by editing the ssl files (most relevant ones shown below) but some of those will get overwritten as part of any Plesk Upgrade i.e. those manual edits that differ from the systen settings (see below). So perhaps easier all round, is if you specify them all (Ciphers & TLS Protocols) via CLI as per this article: How to enable or disable TLS protocol versions in Plesk for Linux? which it appears you have tried already, but that's assuming that you added the cipher list as well as just the actual command that you've posted? You need to restart the relevant services afterwards too (as you'll know already).

As you've also already tried, you can use SSL-It too (we don't) but the most handy cipher configs / references, regardless of which option you choose are:

Security/Server Side TLS - MozillaWiki
Mozilla SSL Configuration Generator

Finally, this reference: "...but still doesn't appear on the SSL Labs test" There is a results cache with SSL Labs, which you need to overwrite / replace which you probably knew already, but just in case, there's quite a few other applications to download, online options to use, if, your're specifically checking for your expected ciphers / usage etc. e.g. drwetter/testssl.sh which gives lots of additional data as well as your cipher list.

Our own, most relevant, manual edit SSL files:
apache: /etc/apache2/mods-available/ssl.conf
dovecot: /etc/dovecot/conf.d/11-plesk-security-ssl.conf
nginx: /etc/nginx/conf.d/ssl.conf
postfix: /etc/postfix/main.cf
proftpd: /etc/proftpd.d/ssl.conf
sw-cp-server: /etc/sw-cp-server/conf.d/ssl.conf

Tyson_Moore · Mar 4, 2021

learning_curve said:
@Tyson_Moore You've not mentioned nginx, so you're probably not using it at all?

You can set all ciphers manually, by editing the ssl files (most relevant ones shown below) but some of those will get overwritten as part of any Plesk Upgrade i.e. those manual edits that differ from the systen settings (see below). So perhaps easier all round, is if you specify them all (Ciphers & TLS Protocols) via CLI as per this article: How to enable or disable TLS protocol versions in Plesk for Linux? which it appears you have tried already, but that's assuming that you added the cipher list as well as just the actual command that you've posted? You need to restart the relevant services afterwards too (as you'll know already).

As you've also already tried, you can use SSL-It too (we don't) but the most handy cipher configs / references, regardless of which option you choose are:

Security/Server Side TLS - MozillaWiki
Mozilla SSL Configuration Generator

Finally, this reference: "...but still doesn't appear on the SSL Labs test" There is a results cache with SSL Labs, which you need to overwrite / replace which you probably knew already, but just in case, there's quite a few other applications to download, online options to use, if, your're specifically checking for your expected ciphers / usage etc. e.g. drwetter/testssl.sh which gives lots of additional data as well as your cipher list.

Our own, most relevant, manual edit SSL files:
apache: /etc/apache2/mods-available/ssl.conf
dovecot: /etc/dovecot/conf.d/11-plesk-security-ssl.conf
nginx: /etc/nginx/conf.d/ssl.conf
postfix: /etc/postfix/main.cf
proftpd: /etc/proftpd.d/ssl.conf
sw-cp-server: /etc/sw-cp-server/conf.d/ssl.conf

Hey learning_curve,

Yeah, I've tried pretty much everything.

We're using LiteSpeed, so you have to have nginx disabled.

Concentrating mainly on
apache: /etc/httpd/conf.d/ssl.conf
sw-cp-server: /etc/sw-cp-server/conf.d/ssl.conf

Yeah, restarted services each time.

Actually it might help to also mention we're on CloudLinux 7 (7.9). Plesk only has openssl 1.0.2k-21.el7_9.

Each time I've run the SSL Labs test I've clicked the "clear cache" link.

When running the below, it connects:
openssl s_client -cipher DHE-RSA-AES128-GCM-SHA256 -connect localhost:8443 -tls1_2

I then saw ssl_dhparam in the /etc/sw-cp-server/conf.d/ssl.conf so I did some searching and found some obscure references to SSLDHParametersFile. So now I am generating a 4096 bit file to link in /etc/httpd/conf.d/ssl.conf and see if that allows usage of DHE ciphers.

learning_curve · Mar 4, 2021

Tyson_Moore said:
We're using LiteSpeed, so you have to have nginx disabled.

Thought so, but was worth double checking

Tyson_Moore said:
Concentrating mainly on
apache: /etc/httpd/conf.d/ssl.conf
sw-cp-server: /etc/sw-cp-server/conf.d/ssl.conf

Understood

Tyson_Moore said:
Yeah, restarted services each time / Each time I've run the SSL Labs test I've clicked the "clear cache" link.

Thought so, but again was worth double checking

Tyson_Moore said:
Actually it might help to also mention we're on CloudLinux 7 (7.9). Plesk only has openssl 1.0.2k-21.el7_9.

You won't be using TLSv1.3 (and it's ciphers) currently then, as you already know you need OpenSSL 1.1.1* to do so. You're not using nginx either, which Plesk used as an effective TLSv1.3 workaround for users that needed TLSv1.3, but whose Apache and/or OS didn't provide OpenSSL 1.1.1* at the time / historically.

Tyson_Moore said:
When running the below, it connects:
openssl s_client -cipher DHE-RSA-AES128-GCM-SHA256 -connect localhost:8443 -tls1_2

Yep, just as we can, but also with the -tls1_3 alternative too, which you can't test / have no need to anyway (see above). This is one form of cipher confirmation yes, but isn't giving you the answer(s) that you need right now.

Tyson_Moore said:
I then saw ssl_dhparam in the /etc/sw-cp-server/conf.d/ssl.conf so I did some searching and found some obscure references to SSLDHParametersFile. So now I am generating a 4096 bit file to link in /etc/httpd/conf.d/ssl.conf and see if that allows usage of DHE ciphers.

This shouldn't actually make any difference, as the 4096 DHParam is used on some ciphers but not all (depends on your cipher list).
If you do download and run drwetter/testssl.sh you'll see to which ciphers it's applied on your cipher list (and lots more too)

FWIW - In our own /etc/sw-cp-server/conf.d/ssl.conf file we run:
#SSL DHParam
ssl_dhparam /etc/ssl/certs/dhparam.pem;
This does work perfectly as / when it's needed.

Back shortly with a couple more items...

Tyson_Moore · Mar 4, 2021

learning_curve said:
Thought so, but was worth double checking

Understood

Thought so, but again was worth double checking

You won't be using TLSv1.3 (and it's ciphers) currently then, as you already know you need OpenSSL 1.1.1* to do so. You're not using nginx either, which Plesk used as an effective TLSv1.3 workaround for users that needed TLSv1.3, but whose Apache and/or OS didn't provide OpenSSL 1.1.1* at the time / historically.

Yep, just as we can, but also with the -tls1_3 alternative too, which you can't test / have no need to anyway (see above). This is one form of cipher confirmation yes, but isn't giving you the answer(s) that you need right now.

This shouldn't actually make any difference, as the 4096 DHParam is used on some ciphers but not all (depends on your cipher list).
If you do download and run drwetter/testssl.sh you'll see to which ciphers it's applied on your cipher list (and lots more too)

FWIW - In our own /etc/sw-cp-server/conf.d/ssl.conf file we run:
#SSL DHParam
ssl_dhparam /etc/ssl/certs/dhparam.pem;
This does work perfectly as / when it's needed.

Back shortly with a couple more items...

It appears LiteSpeed uses its own openssl:

SSL Version

OpenSSL/1.1.1d

I remember they had DH Param settings, but it appears they have taken them out in one of the later/the latest version. I guess because most servers should have a late enough version of Apache and openssl to handle the ciphers needed. The majority of settings/configuration are taken from Apache. Maybe I should just prepare for a rebuild and migrate everything to the latest CloudLinux. Try to stay up with/ahead of the times.

learning_curve · Mar 4, 2021

@Tyson_Moore

Maybe I should just prepare for a rebuild and migrate everything to the latest CloudLinux.

Maybe, but not yet...

Two additional ways of running full cipher checks via CLI
Ideally - for clarity - from a remote, local machine NOT your actual server (& sorry if you've already run these previously)

1) $ nmap --script ssl-enum-ciphers -p 443 yourdomain.com

2) Install SSLSCAN locally (in our case we did it via brew on MacOS Big Sur) and then very simply: $ sslscan yourdomain.com

Thinking these will perhaps give you more related / relative info (at this point in time) than the "openssl s_client ..." type query does

learning_curve · Mar 4, 2021

@Tyson_Moore If/when you have run drwetter/testssl.sh on your server or, run SSLSCAN locally or, run nmap from either, will you post the results - edited for privacy? Plus, out of interest, how were you testing the ciphers being applied on your Plesk panel? SSL Labs itself, only tests on port 443 as you know, so that's fine for your domain (or domains), but testing the ciphers being applied on your Plesk panel i.e. yourdomain.com:8443, where yourdomain.com is the FQDN you're hosting Plesk, on can't be run on the SSL Labs main site. You would need Qualys CertView | Qualys, Inc. instead. Is that where you tested them? Or perhaps you used another online option: Immuniweb and a PCSYNC HTTPS test where you can specify yourdomain.com:8443 and receive the correct results?

Plesk Panel # sw-cp-serverd -V & WebServer # nginx -V are separate nginx installations anyway, as you've seen, but the only other thing might be causing your issues is, a misconfig when initially enabling lightspeed, which is normally fairly straightforward and disables WebServe # nginx -V as part of the process.

Tyson_Moore · Mar 4, 2021

learning_curve said:
@Tyson_Moore If/when you have run drwetter/testssl.sh on your server or, run SSLSCAN locally or, run nmap from either, will you post the results - edited for privacy? Plus, out of interest, how were you testing the ciphers being applied on your Plesk panel? SSL Labs itself, only tests on port 443 as you know, so that's fine for your domain (or domains), but testing the ciphers being applied on your Plesk panel i.e. yourdomain.com:8443, where yourdomain.com is the FQDN you're hosting Plesk, on can't be run on the SSL Labs main site. You would need Qualys CertView | Qualys, Inc. instead. Is that where you tested them? Or perhaps you used another online option: Immuniweb and a PCSYNC HTTPS test where you can specify yourdomain.com:8443 and receive the correct results?

Plesk Panel # sw-cp-serverd -V & WebServer # nginx -V are separate nginx installations anyway, as you've seen, but the only other thing might be causing your issues is, a misconfig when initially enabling lightspeed, which is normally fairly straightforward and disables WebServe # nginx -V as part of the process.

learning_curve · Mar 5, 2021

@Tyson_Moore aka a man of few words

Looks like you've used nmap --script ssl-enum-ciphers -p 443 yourdomain.com for that ^ & presumably it's just 1 of your hosted domains, not your Plesk Panel, but is that ALL of the output? The results usually show a letter grade (A through F) indicating the strength of the connection AND ephemeral DH parameters too. EG here's one of our own cipher queries, TLSv1.2 only, just on 1 domain, using the same script command as you, where you can see the missing elements:

443/tcp open ssl/http nginx
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

If you run nmap again, but using the more enhanced version of that script: nmap -sV --script ssl-enum-ciphers our domain.com you can check a lot further, i.e. on many other ports in addition to 443, even port 8443/tcp open ssl/https-alt sw-cp-server, i.e. your Plesk Panel ((shown as an edited extract below, from the much more detailed results output) but again here, it's only tested on TLSv1.2 just like yourself (Not TLSv1.3)

8443/tcp open ssl/https-alt sw-cp-server
| fingerprint-strings:
| FourOhFourRequest:
| HTTP/1.1 301 Moved Permanently
| Server: sw-cp-server
~~~~~~~~~ EDIT ~~~~~~~~~
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

All of the details (by port number) are followed by service data detail too in the results, but your'e only looking for the cipher detail in this case.

It appears that you've either, edited the results details, down to the absolute minumim before posting, OR, there is (as you've already suspected) a config issue (somewhere) illustrated by the missing data & only showing - strong suffix in your results, which is just the strength of the specifc cipher that it follows.

Can you not just raise a support ticket instead of spending lots more perosnal time testing, re-testing and trying to find the (possible) mis-confg?

Tyson_Moore · Mar 5, 2021

@learning_curve

Yeah, was kind of over all the time spent on this, so just posted what I could be bothered doing

I could raise a ticket, but I'm pretty stubborn.

I'm wondering if you have a later version on nmap/openssl...
Nmap version 6.47 ( Nmap: the Network Mapper - Free Security Scanner )
Platform: x86_64-redhat-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.1e libpcre-8.32 libpcap-1.5.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

This is from our cPanel server to the Plesk server:

Starting Nmap 6.47 ( Nmap: the Network Mapper - Free Security Scanner ) at 2021-03-06 07:59 NZDT
Nmap scan report for
Host is up (0.00053s latency).
rDNS record for
Not shown: 959 filtered ports, 26 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
23/tcp open ssh OpenSSH 7.4 (protocol 2.0)
25/tcp open smtp Postfix smtpd
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
53/tcp open domain ISC BIND none
80/tcp open http LiteSpeed httpd
106/tcp open tcpwrapped
110/tcp open pop3 Dovecot pop3d
143/tcp open imap Dovecot imapd
443/tcp open https LiteSpeed
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
465/tcp open smtps?
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
587/tcp open smtp Postfix smtpd
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
993/tcp open imaps?
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
995/tcp open pop3s?
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
3306/tcp open mysql MySQL 5.5.5-10.1.48-MariaDB-cll-lve
8443/tcp open https-alt?
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at Nmap Fingerprint Submitter 2.0 :

Service detection performed. Please report any incorrect results at Nmap OS/Service Fingerprint and Correction Submission Page .
Nmap done: 1 IP address (1 host up) scanned in 52.74 seconds

Tyson_Moore · Mar 5, 2021

@learning_curve

Find it odd that 3306 is open, maybe I did set it for external connections, then.

And for some reason I hadn't installed nmap on the Plesk server

Tyson_Moore · Mar 5, 2021

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS	128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS	256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS	256

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS	256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS	128
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS	256

Just a little light reading

learning_curve · Mar 5, 2021

Tyson_Moore said:
I could raise a ticket, but I'm pretty stubborn.

The challange ahead, will consist of....

Tyson_Moore said:
I'm wondering if you have a later version on nmap/openssl...
Nmap version 6.47 ( Nmap: the Network Mapper - Free Security Scanner )
Platform: x86_64-redhat-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.1e libpcre-8.32 libpcap-1.5.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Both on local machines and on our server, we're using Nmap version 7.91, so yes, a later version than the one you're using there.

Our server version FWIW:
Nmap version 7.91 ( Nmap: the Network Mapper - Free Security Scanner )
Platform: x86_64-ubuntu-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.1 libssh2-1.8.0 libz-1.2.11 libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Not an nmap, version difference expert but it might be a factor in the different ouputs (besides different OS / no nginx etc).

learning_curve · Mar 5, 2021

Tyson_Moore said:
This is from our cPanel server to the Plesk server:
~~~~
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
~~~~

Plus

Tyson_Moore said:
This is from our Plesk server to the cPanel server (ewwww... TLS 1.0 and 1.1 should be disabled! Oh, I think I recall compatibility issues with email clients):
~~~~
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
~~~~

In both, it's the same indication as before (caveat: nmap version number diffs...) of having ciphers and their ratings in place, but no grade (A through F) indicating the strength of the connection AND no ephemeral DH parameters being visible. Are those ciphers actually being utilised? Possible Config issue? Ticket?

))

Your last post, shows the SSL Labs analysis of the chosen ciphers in more detail, that's all really. What about their next section? The Handshake Simulation?
Here's an example, edited extract so that it's only showing TLSv1.2 & two browsers, from within the Handshake Simulation section when we run it on a domain:

Chrome 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Chrome 69 / Win 7 R RSA 2048 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS
Firefox 31.3.0 ESR / Win 7 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 47 / Win 7 R RSA 2048 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 62 / Win 7 R RSA 2048 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS

Tyson_Moore · Mar 5, 2021

Chrome 49 / XP SP3	RSA 2048 (SHA256)	TLS 1.2 > h2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Chrome 69 / Win 7 R	RSA 2048 (SHA256)	TLS 1.2 > h2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS
Chrome 70 / Win 10	-	TLS 1.3	TLS_AES_128_GCM_SHA256 ECDH x25519 FS
Chrome 80 / Win 10 R	-	TLS 1.3	TLS_AES_128_GCM_SHA256 ECDH x25519 FS
Firefox 31.3.0 ESR / Win 7	RSA 2048 (SHA256)	TLS 1.2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 47 / Win 7 R	RSA 2048 (SHA256)	TLS 1.2 > h2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 49 / XP SP3	RSA 2048 (SHA256)	TLS 1.2 > h2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Firefox 62 / Win 7 R	RSA 2048 (SHA256)	TLS 1.2 > h2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS
Firefox 73 / Win 10 R	-	TLS 1.3	TLS_AES_128_GCM_SHA256 ECDH x25519 FS

learning_curve · Mar 6, 2021

@Tyson_Moore

So...... what is the actual problem then?

Previously, this was the post:

....Yet going through SSL Labs test doesn't seem to come up with them no matter what I do

Yet, in the preceding couple of posts, we can see the ciphers that you've chosen, in the order you've specified them on your server, all clearly shown in SSL Labs.
The phrase used (shown above) gave the impression (but probably unintentionally) that NO ciphers could be sen in SSL Labs.... as opposed to not ALL ciphers.

IS the ACTUAL real query...; WHY, can you see the RSA ciphers, but NOT the ECDSA ciphers on an SSL Labs report?

IF that ^^ is the actual query, than that would make sense!
Plus that ^^ is related to what you can actually see on SSL Labs in your tests now i.e. RSA ciphers only and not both RSA AND ECDSA ciphers.

Plesk, via for their own technical reasons, by default, will only present SSL via RSA OR ECDSA and then, hence the appropriate ciphers only. NOT both. Look at the post in that link and all of the subsequent posts on the same or related subject, as to why (back then) but this situation has not changed - AFIK.
It's possible to select which protocol is used via Plesk panel (panel.ini editor extention) which will then present the appropriate ciphers, as you have seen (RSA):

[ext-letsencrypt]

key-algorithm

RSA

OpenSSL key type. Can be RSA or ECDSA.

You could customise this default setup, so that both RSA AND ECDSA are presented and then allow the browser to choose whichever protocol & appropriate ciphers it wanted and that's mentioned in the post via the link above too. If we ignore the caveat covering our nmap different versions which maybe responsible for the different results content & also ignore that all the other testing methods / locations haven't been used, have we not just solved the problem/no poblem?

Tyson_Moore · Mar 8, 2021

@learning_curve

Thanks for all that!

I'm satisfied for now

The ones we needed for the POLipay plugin in WHMCS are the ones below:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (P384)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (P256, P384)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

The ones we have now are:

# TLS 1.3 (server has no preference)
TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA)
TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA)
TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA)

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA)

Now I can attempt to make a payment and see if the whole process goes through

And if it doesn't, then I can go back to the guys that made the plugin, and then back to POLipay themselves.

learning_curve · Mar 8, 2021

@Tyson_Moore Good to read that real progress has been made! If the process does go all the way through/is succesful (which looking at what you've posted above and in theory it should be now) Then please post / confirm and change this thread to 'Resolved'. << Useful for other readers with a similar problem

Tyson_Moore · Mar 13, 2021

@learning_curve Finally got around to testing it and the process went right through!

Resolved Issue applying SSL Ciphers

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

Tyson_Moore

Basic Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

learning_curve

Silver Pleskian

Tyson_Moore

Basic Pleskian

Similar threads