Resolved Changing DH-key from 2048 to 4096

[mr-wolf]

Hmmm, so the daemon has problems with the curves...
I would check which one of those 3 and leave that one out.

Still strange yours has a different daemon. You are running CentOS which may have been compiled with another openSSL. I am on Ubuntu 16.0.4.3.
After you found out which curve it is you could raise an issue with Plesk.

 

[learning_curve]

Any thoughts on an independent method for verifying the 4096 DH-key? We can't see any way simple of doing it with our setup or, explain why it's now not shown on the SSL/TLS Server Test | High-Tech Bridge reports when it was previously

 

[mr-wolf]

On my servers it always responsed correctly, so I'm guessing your server somehow doesn't apply it.
Raise an issue and give the info that it is working on an Ubuntu system.

No, I know of no other test sites.
Have you sorted out which elliptical curve is causing the problem?


As it's just nginx just run this:

sw-cp-serverd -V

nginx version: nginx/1.11.10
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/sw-cp-serverd --conf-path=/etc/sw-cp-server/config --error-log-path=/var/log/sw-cp-server/error_log --http-log-path=/var/log/sw-cp-server/access.log --lock-path=/var/lock/sw-cp-server.lock --pid-path=/run/sw-cp-server.pid --http-client-body-temp-path=/var/lib/sw-cp-server/body --http-fastcgi-temp-path=/var/lib/sw-cp-server/fastcgi --http-proxy-temp-path=/var/lib/sw-cp-server/proxy --http-scgi-temp-path=/var/lib/sw-cp-server/scgi --http-uwsgi-temp-path=/var/lib/sw-cp-server/uwsgi --user=sw-cp-server --group=sw-cp-server --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_v2_module --add-module=/home/builder/buildbot/sw-cp-server-trunk-bubt1604x64/build/sw-cp-server/work/lua-nginx-module-0.10.7 --add-module=/home/builder/buildbot/sw-cp-server-trunk-bubt1604x64/build/sw-cp-server/work/ngx_devel_kit-0.2.19

Compare that output to the one you're getting from nginx -V

This means you can also run sw-cp-serverd -t (so you don't need to restart the server to see faults). sw-cp-serverd -T may be of interest too....



I somehow don't like CentOS (gut-feeling) and the missing if-up.d folders for iptables. So I always prefer Debian based systems (where I don't like dash) when I have a choice.
I therefore don't know much of the CentOS specifics. I did, somewhere on this forum, read a post from someone complaining about CentOS's openssl (1.01???) which may be the root cause of your problem.

Resolved - After OpenSSL upgrade all websites show old version in phpinfo

 

[learning_curve]

Hmmm, so the daemon has problems with the curves...
I would check which one of those 3 and leave that one out. Still strange yours has a different daemon. You are running CentOS which may have been compiled with another openSSL. I am on Ubuntu 16.0.4.3.
After you found out which curve it is you could raise an issue with Plesk.

Thanks. We will do this, but it's lower down our list at present, because all 3 curves ARE functional when applied via /etc/nginx/conf.d/ssl.conf see THIS pic and this is our current, live setup

On my servers it always responsed correctly, so I'm guessing your server somehow doesn't apply it. Raise an issue and give the info that it is working on an Ubuntu system

Now in progress

No, I know of no other test sites

Amazing that if you're still on OpenSSL 1.0.1 (as we and most other CentoOS 6/7 users are) anywhere we look for this info is like looking down a black hole...

Have you sorted out which elliptical curve is causing the problem?

See note above ^^

As it's just nginx just run this:
sw-cp-serverd -V

nginx version: nginx/1.11.10
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/sw-cp-serverd --conf-path=/etc/sw-cp-server/config --error-log-path=/var/log/sw-cp-server/error_log --http-log-path=/var/log/sw-cp-server/access.log --lock-path=/var/lock/sw-cp-server.lock --pid-path=/run/sw-cp-server.pid --http-client-body-temp-path=/var/lib/sw-cp-server/body --http-fastcgi-temp-path=/var/lib/sw-cp-server/fastcgi --http-proxy-temp-path=/var/lib/sw-cp-server/proxy --http-scgi-temp-path=/var/lib/sw-cp-server/scgi --http-uwsgi-temp-path=/var/lib/sw-cp-server/uwsgi --user=sw-cp-server --group=sw-cp-server --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_v2_module --add-module=/home/builder/buildbot/sw-cp-server-trunk-bubt1604x64/build/sw-cp-server/work/lua-nginx-module-0.10.7 --add-module=/home/builder/buildbot/sw-cp-server-trunk-bubt1604x64/build/sw-cp-server/work/ngx_devel_kit-0.2.19

Compare that output to the one you're getting from nginx -t
This means you can also run sw-cp-serverd -t (so you don't need to restart the server to see faults). sw-cp-serverd -T may be of interest too....

Very, very useful details for us. Thanks

I somehow don't like CentOS (gut-feeling) and the missing if-up.d folders for iptables. So I always prefer Debian based systems (where I don't like dash) when I have a choice.
I therefore don't know much of the CentOS specifics. I did, somewhere on this forum, read a post from someone complaining about CentOS's openssl (1.01???) which may be the root cause of your problem.
Resolved - After OpenSSL upgrade all websites show old version in phpinfo

Yes, very frustrating to put it mildly. We're on the latest CentOS 7.3 release and 7.4 is 'immenent' which may have OpenSSL upgrade included. There are many online 'hacks' to upgrade OpenSSL on CentOS 7, but we haven't seen any yet, that appear to be 100% reliable / functional / error free / don't cause collateral damage elsewhere / etc, so we'll just need to wait for the official release of 7.4 and hope that 1.0.2 IS included in it...

 

[mr-wolf]

Thanks. We will do this, but it's lower down our list at present, because all 3 curves ARE functional when applied via /etc/nginx/conf.d/ssl.conf

I don't understand your motives here. I thought you were trying to secure your Plesk interface (on 8443) as good as the normal https server (on 443).
By defining those 3 preferred curves you're somehow including a curve (or 2?) that the sw-cp-server is not aware of because the Plesk team compiled it with an older OpenSSL (for CentOS). Why the normal nginx package on CentOS is modern and the sw-cp-server is old may not be deliberate.

sw-cp-server is not supplied by CentOS, but by Plesk.

AFAIK the sw-cp-server is just a custom compiled Nginx defined to use alternate config files. Plesk could compile it again using a server with OpenSSL 1.02 and distribute that.


I still have 1 CentOS 5.11 server and on that one the gap between the 2 Nginx servers is huge.
Note that the Nginx on my more than 5-year old server (5.11) is newer than the one on my Ubuntu 16.


sw-cp-serverd -V

nginx version: nginx/1.9.2
built with OpenSSL 1.0.1p 9 Jul 2015
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/sw-cp-serverd --conf-path=/etc/sw-cp-server/config --error-log-path=/var/log/sw-cp-server/error_log --http-log-path=/var/log/sw-cp-server/access.log --lock-path=/var/lock/sw-cp-server.lock --pid-path=/var/run/sw-cp-server.pid --http-client-body-temp-path=/var/lib/sw-cp-server/body --http-fastcgi-temp-path=/var/lib/sw-cp-server/fastcgi --http-proxy-temp-path=/var/lib/sw-cp-server/proxy --http-scgi-temp-path=/var/lib/sw-cp-server/scgi --http-uwsgi-temp-path=/var/lib/sw-cp-server/uwsgi --user=sw-cp-server --group=sw-cp-server --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_spdy_module --add-module=/home/builder/buildbot/sw-cp-server-2.2.1-bcos5x64/build/sw-cp-server/work/lua-nginx-module-0.9.15 --add-module=/home/builder/buildbot/sw-cp-server-2.2.1-bcos5x64/build/sw-cp-server/work/ngx_devel_kit-0.2.19 --with-openssl=/home/builder/buildbot/sw-cp-server-2.2.1-bcos5x64/build/sw-cp-server/work/openssl-1.0.1p --with-openssl-opt='enable-tlsext zlib no-idea no-mdc2 no-rc5 no-ec no-ecdh no-ecdsa no-shared -fpic'

nginx -V

nginx version: nginx/1.11.1
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --modules-path=/usr/share/nginx/modules --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-ipv6 --with-file-aio --with-http_v2_module --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --with-openssl=/home/builder/buildbot/nginx-1.11.1-bcos5x64/build/nginx/work/openssl-1.0.2k --with-openssl-opt='enable-tlsext zlib no-idea no-mdc2 no-rc5 no-ssl2 no-shared -fpic'

 

[learning_curve]

I don't understand your motives here. I thought you were trying to secure your Plesk interface (on 8443) as good as the normal https server (on 443)

We are.... and we think....we have? The pic (link) on our last post, is taken from the server (plesk interface) on port 8443, not a domain on 443. You can add the port as part of the search criteria

By defining those 3 preferred curves you're somehow including a curve (or 2?) that the sw-cp-server is not aware of because the Plesk team compiled it with an older OpenSSL (for CentOS). Why the normal nginx package on CentOS is modern and the sw-cp-server is old may not be deliberate

We both have no idea to be fair do we? Somebody other than ourselves will know the answer... probably

sw-cp-server is not supplied by CentOS, but by Plesk

Yes we already were aware of that because of previous issues

AFAIK the sw-cp-server is just a custom compiled Nginx defined to use alternate config files. Plesk could compile it again using a server with OpenSSL 1.02 and distribute that

But will they? They haven't done so far, that we're aware of anyway....

I still have 1 CentOS 5.11 server and on that one the gap between the 2 Nginx servers is huge.
Note that the Nginx on my more than 5-year old server (5.11) is newer than the one on my Ubuntu 16

Our setup is different (as you've already mentioned) nginx is fine but the OpenSSL status in sw-cp-server is just #awkward

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
<Snip>

# nginx -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled<Snip>

 

[mr-wolf]

How very strange was this now I decided to apply the tested config to all my other servers.
My ancient CentOS 5.11 (end-of-life) running Plesk 12.5.3 has no problems getting the "modern config".
One other server does has have a problem and that's my Ubuntu 14.04 LTS server running Plesk 17.5.3.

That sw-cp-serverd comes closest to the one you have.
I was able to get that one to work by disabling 2 of those preferred curves....

# sw-cp-serverd -V

nginx version: nginx/1.11.10
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled

cat /etc/sw-cp-server/conf.d/ssl_extra.conf

add_header              Strict-Transport-Security max-age=15768000 always;
ssl_dhparam             /etc/dhparam/dhparam4096.pem;
#ssl_ecdh_curve          secp521r1:secp384r1:prime256v1;
ssl_ecdh_curve          prime256v1;

 

[learning_curve]

Yes, it doesn't make sense somehow / somewhere does it?
How can our sw-cp-server not be 'comfortable' with some of the curves when tested on the command line but... when tested externally, it's fine (in our case) as per the image we posted. There is some thing that we don't fullly understand, yet, obviously.....

 

[mr-wolf]

Yes, it doesn't make sense somehow / somewhere does it?
How can our sw-cp-server not be 'comfortable' with some of the curves when tested on the command line but... when tested externally, it's fine (in our case) as per the image we posted. There is some thing that we don't fullly understand, yet, obviously.....

The OpenSSL on your system is not applicable here...
It's the OpenSSL-version on the system of the Plesk development team that compiled the sw-cp-server (Nginx really).

The sw-cp-server on my CentOS 5.11, Plesk 12.5.3 is using OpenSSL 1.0.1p 9 Jul 2015
Yours, on a more modern CentOS with Plesk Onyx is using OpenSSL 1.0.1f 6 Jan 2014

They should supply a modern sw-cp-server in their distribution list.
Maybe it's not even Plesk's fault now I'm thinking. I am using distributions of Strato and it could well be that the sw-cp-server there is old.
The CentOS 5.11 server is not a Strato server.
It could be solved by changing the repo...

By now I would like some comment of @UFHH01 or @IgorG

 

[learning_curve]

Yours, on a more modern CentOS with Plesk Onyx is using OpenSSL 1.0.1f 6 Jan 2014

There's a typo there we think. Ours is even older (re-post)

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
<Snip>

 

[mr-wolf]

On my system (Ubuntu 14) the sw-cp-serverd rejects the 2 curves secp521r1 secp384r1 both in ssl.conf and ssl_extra.conf.
This is to be expected of course.

Are these 3 curves really applied on that daemon if you test it externally?
Have you tried stop the daemon and start it again?
There's totally no logic that it rejects it in /etc/sw-cp-server/conf.d/ssl_extra.conf and accept it in /etc/sw-cp-server/conf.d/ssl.conf
It's just a bunch of configs that become 1 config to be fed to the daemon.

 

[learning_curve]

On my system (Ubuntu 14) the sw-cp-serverd rejects the 2 curves secp521r1 secp384r1 both in ssl.conf and ssl_extra.conf. This is to be expected of course

Yes, ours rejected both ssl.conf and ssl_extra.conf too.
We tested this option way back when it first happened (but we did not post that specific detail)

Are these 3 curves really applied on that daemon if you test it externally?

We have never tested it externally because we moved the curves etc out of those files and into /etc/nginx/conf.d/ssl.conf instead. We tested it (command line - okay) and it was this (presumably) that we tested externally (see previous posts about :8443 specific tests etc)

Have you tried stop the daemon and start it again?

Yes as per your previous posted guidance / our posts; the results you're familiar with now.

There's totally no logic that it rejects it in /etc/sw-cp-server/conf.d/ssl_extra.conf and accept it in /etc/sw-cp-server/conf.d/ssl.conf It's just a bunch of configs that become 1 config to be fed to the daemon.

Correct and fully agreed. See 1st answer above. We're with you 100%

 

[learning_curve]

No updates or comments yet on this thread yet, from those forum members ( mentioned earlier by @mr-wolf ) whose input would be very greatfully received here. Possibly worth watching THIS thread instead just in case...

 

[mow]

We have never tested it externally because we moved the curves etc out of those files and into /etc/nginx/conf.d/ssl.conf instead. We tested it (command line - okay) and it was this (presumably) that we tested externally (see previous posts about :8443 specific tests etc)

As you were told multiple times, that is the config file for the other nginx that is serving all the configured domains' content on :80 and :443, not the plesk-supplied nginx disguised as sw-cp-serverd that runs plesk itself on :8443.
That other nginx is probably newer and built against a much newer OpenSSL (see "nginx -V") than the sw-cp-serverd, and thus able to support those curves.

 

[learning_curve]

As you were told multiple times, that is the config file for the other nginx that is serving all the configured domains' content on :80 and :443, not the plesk-supplied nginx disguised as sw-cp-serverd that runs plesk itself on :8443.
That other nginx is probably newer and built against a much newer OpenSSL (see "nginx -V") than the sw-cp-serverd, and thus able to support those curves.

Your above post, may not possibly be quite up to speed... Yes that was very clear to all of us participating in this thread, several posts before the one you have quoted, which in actual fact, was a post to 'specifically' answer a 'specific' question, raised by @mr-wolf Please re-examine.

In addition, our subsequent post on this thread (which you may not have read to be fair) which was also prior to your post;

Possibly worth watching THIS thread instead just in case...

covers sw-cp-serverd -V etc etc in great detail (and has a purposeful resolution)

 

[Walter]

I had a similar desire to update DH parms on my Plesk Onyx system. I'm always a little hesitant with performing direct mods to source files rather than using a Plesk commands where available.

The command below will alter your dhparm from whatever it is set 2048 or other to 4096. The -G command recompiles it as well. This applies across the board. --strong-dh is required when using dhparams-size.

plesk sbin sslmng --custom --strong-dh --dhparams-size=4096 -G

For additional SSL parms and their usage try:

plesk sbin sslmng --help

Also for some great config advice for protocols and ciphers use:
Cipherli.st - Strong ciphers for Apache, nginx and Lighttpd

 

[learning_curve]

....The command below will alter your dhparm from whatever it is set 2048 or other to 4096. The -G command recompiles it as well. This applies across the board. --strong-dh is required when using dhparams-size...

Thanks @Walter That's interesting and helpful too.

Just so that we can understand your post 100% correctly, are you saying that this is in fact, a "stand alone" method of changing the DH from 2048 to 4096 without ANY other actions when starting with a default Plesk setup? i.e. not needing to run this command in advance: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096 for example, or indeed, any other commands in order to apply the DH value change server-wide?

In addition, if openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096 has already been run, updated SSL and curve changes specified, etc etc then does your post still apply? Or put more simply, is this command then still required?

Finally, other than the one mentioned previously in this thread, are you aware of any other independent method(s) of verifying the DH4096 value?

 

[virtubox]

Thanks @Walter That's interesting and helpful too.

Just so that we can understand your post 100% correctly, are you saying that this is in fact, a "stand alone" method of changing the DH from 2048 to 4096 without ANY other actions when starting with a default Plesk setup? i.e. not needing to run this command in advance: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096 for example, or indeed, any other commands in order to apply the DH value change server-wide?

In addition, if openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096 has already been run, updated SSL and curve changes specified, etc etc then does your post still apply? Or put more simply, is this command then still required?

Finally, other than the one mentioned previously in this thread, are you aware of any other independent method(s) of verifying the DH4096 value?

You can use CryptCheck to check your DH key size.
But if some ECDHE curves require the latest openssl release, curves P-384 or P-256 should be compatible without problem.
You can use :

 ssl_ecdh_curve prime256v1;

or

ssl_ecdh_curve secp384r1;

 

[learning_curve]

Thanks @virtubox

Using CryptCheck to check DH key size is a bit random so far...
Yes Port 443 is okay, but it seems impossible (because it runs for ages and then just times out) to run on port 8443
A domain Diffie Hellman result on port 443 was shown as: ECC 256 bits and not 2048 or 4096 when we tried it.
That's a different format than shown in an earlier post HERE
How was your experience when using it?

We already have secp521r1 secp384r1 prime256v1 via ssl_ecdh_curve on nginx and sw-cp-server and they run fine
Using High-Tech Bridge provides a simple confirmation summary on 443 and 8443
List of all elliptic curves supported by the server:
P-521 (secp521r1) (521 bits) Good configuration
P-384 (secp384r1) (384 bits) Good configuration
P-256 (prime256v1) (256 bits) Good configuration
This other thread that we linked earlier, is relevent to this too

 

[virtubox]

Thanks @virtubox

Using CryptCheck to check DH key size is a bit random so far...
Yes Port 443 is okay, but it seems impossible (because it runs for ages and then just times out) to run on port 8443
A domain Diffie Hellman result on port 443 was shown as: ECC 256 bits and not 2048 or 4096 when we tried it.
That's a different format than shown in an earlier post HERE
How was your experience when using it?

We already have secp521r1 secp384r1 prime256v1 via ssl_ecdh_curve on nginx and sw-cp-server and they run fine
Using High-Tech Bridge provides a simple confirmation summary on 443 and 8443
List of all elliptic curves supported by the server:
P-521 (secp521r1) (521 bits) Good configuration
P-384 (secp384r1) (384 bits) Good configuration
P-256 (prime256v1) (256 bits) Good configuration
This other thread that we linked earlier, is relevent to this too

You can use directly openssl via ssh to test your server ssl configuration :

openssl s_client -connect  yourplesk.server.ltd:8443

About ECC , curves P-384 provide the same encryption than a RSA key of 7680 bits. So any ECDHE configuration will be better than a classic DHE configuration.
I do not have any issue with the curves P-256 and P-384.

ssl_ecdh_curve X25519:P-521:P-384; #   new nginx releases 
ssl_ecdh_curve secp521r1:secp384r1; #   normal nginx configuration
ssl_ecdh_curve secp384r1; # old version of nginx