Resolved Changing DH-key from 2048 to 4096

[mr-wolf]

To be complete....
These are the files I added/modified
I modified ssl.conf (it's exactly the same as the ssl.conf I'm using on port 443)

I want to avoid problems with clients using old systems.
On the Plesk interface I could drop TLSv1 I think.
You should maybe drop it entirely (both on 443 and 8443)

cat /etc/sw-cp-server/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:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_stapling on;
ssl_stapling_verify on;

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;

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

add_header Referrer-Policy strict-origin-when-cross-origin;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;

 

[mr-wolf]

So am I right that your mistake was only the wrong interpretation of those sites' output???
Maybe you can PM me the Web Security Company | High-Tech Bridge SA result page of your server

 

[learning_curve]

I have no problems at all applying the different parameters.
Just did several mods to the SSL-setting of the Plesk panel and they all apply and can be seen in Analyse your HTTP response headers

Yes we run A's on there not A+'s but that's because we don't run HTTP Public Key Pinning
We've posted a different thread which mentions THIS aspect of HPKP

[EDIT] just saw the list.... only 1 of these sites will show you the DH-key.

SSL Server Test (Powered by Qualys SSL Labs) can't test other ports than 443
SSL Certificate Checker It gives "no certificates found"
SSL Certificate Checker - Diagnostic Tool | DigiCert.com Gives the key length of 2048, but this is not the dhparam key (I guess that is your mistake)
SSL/TLS Server Test | High-Tech Bridge This site was the only one that gave info on the DH-key and as you can see it's 4096 bits.....

You're posting mesages faster than we can keep up with now but all very useful thank you. We have slightly different results than you and there are other tests as well (which you'll be aware of, more so than we are, we think). We currently don't see a DH-key of 4096 anywhere... yet... However, let us work through all these change options, in a patient, controlled manner and we'll post the update on here tomorrow and PM you the details you asked for (before and after)

 

[mr-wolf]

Here a comparison using the website: SSL/TLS Server Test | High-Tech Bridge

I'm posting the bits where you can see progress using the posted config.
On this site I'm getting A+ with both configs, but that's just the site being too generous.

Note that the DH-key is NOT mentioned in the standard setting as it is not applied at all.
The 2048-bits key that's mentioned is NOT your DH-key, but the certificate itself.
It will therefore NOT change if you change the DH-key!!

STANDARD Plesk settings for control panel on port 8443







MODIFIED Plesk settings for control panel on port 8443

 

[learning_curve]

Here is the update:

We've re-titled this thread to a more specific (and correct) description.

We have made some errors so far, but to be fair, we did say we might do in our first post:

Either... we have misunderstood where the 2048 key length is actually applied (wrong file or wrong instruction) or, in what order the key length is applied (which file has priority etc) or, even simpler, we have misunderstood the 2048 / 4096 process and this change cannot be carried out when using Plesk and the setup that we currently have (see signature). All of our original 2048 files / references etc files are still in place, so we can easily revert back to them if needed, but it's well worth us asking for any guidance before we do that...

However, these errors haven't caused any server or site problems for us at all, so far....

We restored all the files listed in our 1st post, back to exactly as they were, at the time of us making that 1st post in this thread. All services were checked and then re-started. Easy and no problems encountered with this part. The status here, is that by default (presumably of the package we started with) the DK-key is set at 2048, as can bee seen clearly.

Then, we closely worked through all your very helpful posts, but finally focused on THIS one and subsequently added new file versions (with modified content) as & where required. Our results / experience are slightly different from yours... Pre-reading Note: We only use TLSv1.2 anyway and have done since 8th May 2017 when we applied those changes. Currently, our setup each domain on our server independently, mainly, as a result of changes within Plesk that are covered in THIS long thread. Since this thread, new suggestions have arrived on this subject, but we haven't tried or moved over to those yet. So, going back to your post (linked before) here's the results:

/etc/sw-cp-server/conf.d/ssl.conf

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.2;

Note that ssl_stapling is applied by domain in our case, so is not included in our file

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

We are unable to run the content shown in your post as an additional file like this.
We didn't include the add_header line anyway, because it's applied by domain in our case.
The error message produced is this:

# /etc/init.d/sw-cp-server start
Starting sw-cp-server (via systemctl):  Job for sw-cp-server.service failed because the control process exited with error code. See "systemctl status sw-cp-server.service" and "journalctl -xe" for details.

What we tried 1st, was including the content within another version of /etc/sw-cp-server/conf.d/ssl.conf and re-starting the service again, but this didn't work either and the error report is identical to the one above ^^

Undeterred we included the content of this additional file within /etc/nginx/conf.d/ssl.conf instead, which is shown below and which appears to work fine

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.2;
ssl_dhparam /etc/dhparam/dhparam4096.pem;
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

All services were then tested and re-started, with the exception of /etc/proftpd.d/ssl.conf >> see separate note below

/etc/sw-cp-server/conf.d/headers.conf

All items in this file (which we haven't created) are applied by domain in our case.

/etc/proftpd.d/ssl.conf

We removed this line:

<IfModule mod_tls.c>
TLSDHParamFile /usr/local/psa/etc/dhparams2048.pem
</IfModule>

but we haven't replaced it with any 4096 reference - yet
Mainly because we're not sure if we need to.... If we do, it will be this

<IfModule mod_tls.c>
TLSDHParamFile /etc/dhparam/dhparam4096.pem
</IfModule>

A separate post follows shortly re: test results

 

[learning_curve]

Referring to your screen-grabs comparisons using the website: SSL/TLS Server Test | High-Tech Bridge

Yes, the relevant sections on our own server / domains are very similar (e.g. the noticeable reduction of available supported elliptic curves etc) Ours are all TLSv1.2 only as mentioned previously but that's irrelevant anyway here. Most importantly however and for reasons unknown, we cannot see the Diffie-Hellman Parameter Size on any (regardless of port number used for the report...) even though we have in the past....

With our current setup, we're using OpenSSL 1.0.1 although we believe the next Centos upgrade will move this on... Because of that, it's impossible (we think) for us to run any command line code, that will accurately report the DK-key being used... There are available option when using OpenSSL 1.0.2, so fingers crossed for Centos.

Meanwhile, it is possible to check that things elsewhere, see THIS PIC for an example but if we have read things correctly, both 2048 and 4096 with the correct ciphers would pass this anyway.

To cut to the chase, all the changes in our last post now seem fine (we just need to work out the answer for /etc/proftpd.d/ssl.conf and then we're done there (until we move from by domain back to by server setup again) but, we still don't know for definite (yet) if the 4096 DK-Key implementation has worked... because we can't see or rather see where to look so that we can see!

Edit: Even with OpenSSL 1.0.1, we can still use

# openssl dhparam -inform PEM -in /etc/dhparam/dhparam4096.pem -check -text

but the result is only telling us what we already know and not much more...

 

[mr-wolf]

Note that ssl_stapling is applied by domain in our case, so is not included in our file

I don't understand this remark at all.
The sw-cp-server is a completely separate service.

I assume you have, like me, a certain SSL-certificate installed for the Plesk interface and therefore this server running on port 8443
There is no domain section for that.

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

We are unable to run the content shown in your post as an additional file like this.
We didn't include the add_header line anyway, because it's applied by domain in our case.

Again.... don't understand....

The error message produced is this:

# /etc/init.d/sw-cp-server start
Starting sw-cp-server (via systemctl):  Job for sw-cp-server.service failed because the control process exited with error code. See "systemctl status sw-cp-server.service" and "journalctl -xe" for details.

The idea is to run those commands to say if it outputs anything useful
Probably some duplication of directives...
Maybe some useful info about the DH-key

 

[mr-wolf]

cat /etc/proftpd.d/dh.conf

<IfModule mod_tls.c>
TLSDHParamFile /etc/dhparam/dhparam4096.pem
</IfModule>

cat /etc/proftpd.d/ssl.conf

<IfModule mod_tls.c>
  # TLSCipherSuite HIGH:!aNULL:!MD5
  TLSCipherSuite AES128+EECDH:AES128+EDH

  TLSServerCipherPreference on
  TLSProtocol TLSv1.1 TLSv1.2

  TLSLog /var/log/proftp_tls.log

</IfModule>

 

[learning_curve]

/etc/sw-cp-server/conf.d/ssl.conf

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.2;

Note that ssl_stapling is applied by domain in our case, so is not included in our file

I don't understand this remark at all. The sw-cp-server is a completely separate service. I assume you have, like me, a certain SSL-certificate installed for the Plesk interface and therefore this server running on port 8443. There is no domain section for that

We've been asked this before in another thread. It's possibly our explanation above that's causing the misunderstanding. Yes is the answer to your assumption, but here is 'how'. We use a sub-domain (from one of our domains) as the Server ID / Title etc. That domain does have a full, purchased *wildcard SSL certificate which, obviously covers the sub-domain (Server ID / Title) as well. Hence Plesk (and Mail) are also secured using this *wildcard SSL certificate ( access via sub_domain.domain:8443 = plesk login ) not a separate Let's Encrypt SSL certificate** The answer to the query about ssl_stapling above is that ssl_stapling is applied to this domain via "Additional nginx directives" on the domain itself and therefore, to the Server ID (because it's a sub-domain) That... is the 'how' behind the quote above from our previous post. This is a small Screen-Grab taken from the report generated on SSL/TLS Server Test | High-Tech Bridge which is relevant to the above explanation. This report was run on the Server ID (i.e. sub-domain) url not the domain url itself FWIW. We don't provide accounts or hosting for anybody else. The server and all domains etc are only used by us, nobody else has access / logins etc. Your setup will be different we think.

** Let's Encrypt may soon release SSL Certificates c/w *wildcards we understand, in which case, we will change things accordingly. At the time of our initial server setup however, they didn't

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

We are unable to run the content shown in your post as an additional file like this.
We didn't include the add_header line anyway, because it's applied by domain in our case.
The error message produced is this:

# /etc/init.d/sw-cp-server start
Starting sw-cp-server (via systemctl): Job for sw-cp-server.service failed because the control process exited with error code. See "systemctl status sw-cp-server.service" and "journalctl -xe" for details.

What we tried 1st, was including the content within another version of /etc/sw-cp-server/conf.d/ssl.conf and re-starting the service again, but this didn't work either and the error report is identical to the one above ^^

Again.... don't understand....

This one is a more simple answer If we add a separate file, as you have done: /etc/sw-cp-server/conf.d/ssl_extra.conf we CANNOT restart sw-cp-server. The error message that is produced, we posted as you have seen. If we add the content of /etc/sw-cp-server/conf.d/ssl_extra.conf as extra lines within /etc/sw-cp-server/conf.d/ssl.conf again, we CANNOT restart sw-cp-server and the error message produced is the same. Therefore, we included the content of /etc/sw-cp-server/conf.d/ssl_extra.conf within /etc/nginx/conf.d/ssl.conf instead and this appears to work fine. The answer to not including the add_header line (as you have done) is exactly the same explanation as ssl_stapling above.

It may well be that because of our setup choice (and unless we change this), we will always need to apply items like ssl_stapling by domain and not by server. That's perfectly acceptable to us currently.

 

[learning_curve]

Thanks for your posts on proftpd.d
Our final version of /etc/proftpd.d/ssl.conf therefore, is now this and runs with no errors:

<IfModule mod_tls.c>
TLSCipherSuite 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
TLSServerCipherPreference on
TLSProtocol TLSv1.2
TLSLog /var/log/proftp_tls.log
TLSDHParamFile /etc/dhparam/dhparam4096.pem
</IfModule>

 

[mr-wolf]

What I ment is that you should run the systemctl status sw-cp-server service and journalxt -xe to see the reason for your error.
By posting that very generic line you're not really giving any info

I have a wildcard as well on my psa interface and I apply all those directives on each connection, so also the Plesk interface.


Why would you not turn OCSP stapling on suddenly?
In a "must staple" scenario it wouldn't even work without.

The Nginx on 8443 needs to contact the CA as well to fetch those CA-responses so the client doesn't have to.


By stating "I don't have to do that here as I did this elsewhere" makes me think you don't understand it..

 

[learning_curve]

What I ment is that you should run the systemctl status sw-cp-server service and journalxt -xe to see the reason for your error

Sure we can do that, but whilst you obviously know how to do it, we don't. Could you advise?
We have never run either of these before, because we never have needed to!
We opted to trial a solution closer to the working setup we already had (prior to these changes) which works

By posting that very generic line you're not really giving any info

That is the exact error message provided (as generic as it may appear )
Posting that, has now generated your query, which is fine

Why would you not turn OCSP stapling on suddenly?
In a "must staple" scenario it wouldn't even work without

Sorry we don't understand this question.
We've confirmed that OCSP stapling IS on and you can see that in the pic (link) we included.
"expect staple" and "must staple" we don't use. Do you? They are not compulsory or mandated yet.
However, we have posted separately about them HERE although there's no answers on that thread yet.

The Nginx on 8443 needs to contact the CA as well to fetch those CA-responses so the client doesn't have to. By stating "I don't have to do that here as I did this elsewhere" makes me think you don't understand it..

It's not a question of "don't understand it..." It's simply about understanding exactly what somebody is asking or meaning after reading their post. Depending on the post author and the content of their post, the success rate of this varies wildly. Forums (on all subjects, not just this specific Plesk one) are famous for misunderstandings as a result of misinterpreted posts or intent.

We now have a functional setup that includes the changes we wanted (we think) but we'are unable to independently verify / test that currently, as we've already posted, mainly thanks to the limitations of the Centos / Open SSL package that we have. Very happy to receive your further advice / suggestions (as you've helped us a lot to achieve those changes) and answer any other specific questions as we go along.

 

[mr-wolf]

When Nginx gives you that generic error message you're supposed to execute those commands.
It will give the non-generic error message which will probably really tell you what's going on.

By posting the output of those commands it would give me some real info. The Nginx error message is hardly giving any info.

All the commands I'm using should work on yours.
Try to get that error back and run those subsequent commands

 

[learning_curve]

We can simulate the error again by stopping sw-cp-server, adding /etc/sw-cp-server/conf.d/ssl_extra.conf as a new file and then trying to start sw-cp-server again:

/etc/init.d/sw-cp-server stop

add: /etc/sw-cp-server/conf.d/ssl_extra.conf

/etc/init.d/sw-cp-server start

but the question we were asking is how do we investigate

"systemctl status sw-cp-server.service" 

AND

"journalctl -xe"

e.g. specific command line instruction? If so what is it?

 

[mr-wolf]

We can simulate the error again by stopping sw-cp-server, adding /etc/sw-cp-server/conf.d/ssl_extra.conf as a new file and then trying to start sw-cp-server again:

/etc/init.d/sw-cp-server stop

add: /etc/sw-cp-server/conf.d/ssl_extra.conf

/etc/init.d/sw-cp-server start

but the question we were asking is how do we investigate

"systemctl status sw-cp-server.service" 

AND

"journalctl -xe"

e.g. specific command line instruction? If so what is it?

Those are commands
You need to type them or use copy/paste LOL

 

[learning_curve]

systemctl status sw-cp-server.service:

systemctl status sw-cp-server.service -l
● sw-cp-server.service - Startup script for Plesk control panel server
Loaded: loaded (/usr/lib/systemd/system/sw-cp-server.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2017-09-02 08:27:39 BST; 53s ago
Process: 1075 ExecStart=/usr/sbin/sw-cp-serverd -c /etc/sw-cp-server/config (code=exited, status=0/SUCCESS)
Process: 35662 ExecStartPre=/usr/sbin/sw-cp-serverd -q -t (code=exited, status=1/FAILURE)
Main PID: 1122 (code=exited, status=0/SUCCESS)

systemd[1]: Starting Startup script for Plesk control panel server...
sw-cp-serverd[35662]: nginx: [emerg] OBJ_sn2nid("secp521r1:secp384r1:prime256v1") failed: unknown curve (SSL:)
sw-cp-serverd[35662]: nginx: configuration file /etc/sw-cp-server/config test failed
systemd[1]: sw-cp-server.service: control process exited, code=exited status=1
systemd[1]: Failed to start Startup script for Plesk control panel server.
systemd[1]: Unit sw-cp-server.service entered failed state.
systemd[1]: sw-cp-server.service failed.

 

[learning_curve]

journalctl -xe

Many preceeding lines which are all okay (no errors)
dovecot[1223]: imap-login: Login: user=<******@**********.***>, method=PLAIN, rip=**.***.***.***, lip=**.***.***.***,
postfix/smtpd[35690]: connect from unknown[**.***.***.***]
plesk_saslauthd[35693]: listen=6, status=5, dbpath='/var/spool/postfix/plesk/passwd.db', keypath='/var/spool/postfix
plesk_saslauthd[35693]: privileges set to (89:89) (effective 89:89)
plesk_saslauthd[35693]: No such user ‘******@**********.***’ in mail authorisation database
plesk_saslauthd[35693]: failed mail authenticatication attempt for user '******@**********.***' (password len=12)
postfix/smtpd[35690]: warning: unknown[**.***.***.***]: SASL LOGIN authentication failed: authentication failure
postfix/smtpd[35690]: lost connection after AUTH from unknown[**.***.***.***]
postfix/smtpd[35690]: disconnect from unknown[**.***.***.***]
dovecot[1223]: service=imap, user=******@**********.***, ip=[**.***.***.***]. Logged out rcvd=736, sent=1875
Many more following lines which are all okay (no errors)

 

[learning_curve]

Quick guesses:

In the first post, the line:

ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

when located within /etc/sw-cp-server/conf.d/ssl_extra.conf appears to cause the issue YET..... this is fine when run within /etc/nginx/conf.d/ssl.conf The normal nginx test runs with no errors and the curves appear in the test results (see previous posts)

 

[learning_curve]

In the second, well that's interesting. That's an old login id from months ago, which appears not to have been overwritten / deleted (for whatever reason) within the Plesk Database and is still 'seen' as active. That one, we'll have to go and look for.... Another detective job, but one that isn't really massively connected to DH-Key Changes we would have thought....

 

[learning_curve]

We removed /etc/sw-cp-server/conf.d/ssl_extra.conf and then sucessfully restarted sw-cp-server again
Everything is working normally as a result, using the specific setup that we've posted above earlier .
Your thoughts?