Resolved HSTS doesn't work anymore

Dukemaster · Jul 7, 2017

Hi at all,
by the great help of PLESK Support Articles in this community I successfully activated HSTS globally since half a year on Ubuntu 14 and 16 by 001_own_additional_ssl_hsts_.conf in etc/nginx/conf.d
All 8 domains on server get the result on SSLLABS.

ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;

add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains';

Last week a made a test again and was surprised that HSTS is not working any longer (not with & without www.)
Can You please me finding out why and how to set up again.

I can only imagine why it isn't working:
My changes the last weeks.
Setting successfully OSCP stapling (but I'm relative sure that it worked after this).
Setting net/interface primary IPv4 from DHCP to static and installing two IPv4 for DNS setup
[Own DNS is working since yesterday. "THANKS A LOT @UFHH01 " ! ! !]
Removing IPv6 from webhosting settings of all domains and also in providers domain panel, but IPv6 is still on Plesk and server in background. I'm too afraid removing it totally from PLESK to loose everything (connection/access).
Running Plesk reconfigurator tutorial.
Created an x_y_z_mapping.txt (don't know the exactly name which was located in /<root>/root and deleted it afterwards again, sorry I don't know the tutorial and why. nor if the tutorial came from 1and1 or Plesk. but it had to do with IP related things. sorry to have only these less infos.

Setup is Ubuntu 16.04.2 with Apache and Nginx as Reverse Proxy.
nginx -t absolutely ok

# curl -v ~ Super World | Start ~
* Rebuilt URL to: ~ Super World | Start ~
* Trying 217.160.92.49...
* Connected to domain.com (217.160.92.49) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 696 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: domain.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=domain.com
* start date: Wed, 07 Jun 2017 00:19:00 GMT
* expire date: Tue, 05 Sep 2017 00:19:00 GMT
* issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET / HTTP/1.1
> Host: domain.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Fri, 07 Jul 2017 12:13:20 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: ~ Super World | Start ~
< X-Powered-By: PleskLin
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host domain.com left intact

Lots of greets

Dukemaster · Jul 7, 2017

Settings for Apache & Nginx (Plesk domain)

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /usr/local/psa/var/modules/letsencrypt/etc/live/yoonas.com/fullchain.pem;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;

htaccess:

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.yoonas.com$ [NC]
RewriteRule ^(.*) https://www.yoonas.com/$1 [L,R=301]

# caching
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|svg|swf)$">
ExpiresActive on
ExpiresDefault "access plus 10 days"
Header unset ETag
FileETag None
</FilesMatch>

# compression
<IfModule mod_deflate.c>
<FilesMatch "\.(html|htm|css|js|xml|php|txt|svg)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

# Serve gzip compressed JS files if they exist and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

etc/nginx/conf.d
ssl.conf

ssl_ciphers EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

gzip.conf:

gzip on;
gzip_disable "MSIE [1-6]\\.(?!.*SV1)";
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml image/gif image/jpeg application/atom+xml application/javascript image/png image/tiff image/x-ms-bmp application/font-woff application/json application/msword application/pdf application/postscript application/rtf application/vnd.apple.mpegurl application/vnd.ms-excel application/vnd.ms-fontobject application/vnd.ms-powerpoint application/vnd.wap.wmlc application/vnd.google-earth.kml+xml application/vnd.google-earth.kmz application/x-7z-compressed application/x-cocoa application/x-java-archive-diff application/x-perl application/x-rar-compressed application/x-shockwave-flash application/x-tcl application/x-x509-ca-cert application/xhtml+xml application/xspf+xml application/zip application/octet-stream audio/midi audio/mpeg audio/ogg audio/x-m4a audio/x-realaudio video/3gpp video/mp2t video/mp4 video/mpeg video/quicktime video/webm video/x-flv video/x-m4v video/x-mng video/x-ms-asf video/x-ms-wmv video/x-msvideo;
gzip_vary on;

virtubox · Jul 9, 2017

Dukemaster said:
Settings for Apache & Nginx (Plesk domain)
htaccess:

etc/nginx/conf.d
ssl.conf
gzip.conf:

You can set the headers for HSTS directly in Apache/Nginx Settings (for ipv4 and ipv6) In Additional headers :

HSTS with preloading - XSS Protection - X-frame options - X-content options - and referrer policy

Code:

Referrer-Policy "strict-origin-when-cross-origin"
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
x-xss-protection "1; mode=block"
X-Content-Type-Options: "nosniff"
X-Frame-Options: "sameorigin"

And I have set the following ssl configuration for nginx in /etc/nginx/conf.d/ssl.conf :

Code:

ssl_ciphers 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;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_dhparam /opt/psa/etc/dhparams2048.pem;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 15m;
ssl_session_tickets off;

mr-wolf · Jul 9, 2017

Be really careful when choosing "includeSubDomains".
If you're hosting for others then chances are that one of your clients are hosting a plain http-site you are not aware of.
I was bitten, so just giving you a warning here.
If you're doing it server-wide then carefully examine the chances that this could happen to you too.

I also use the parameter "always".
Some sites will not show "A+" when testing it with "Qualys SSL Labs" if you omit this parameter.

@UFHH01 gave me the idea of creating a new key each week.

ln -s /usr/local/sbin/gen_dhparam /etc/cron.weekly/
cat /usr/local/sbin/gen_dhparam

Code:

#!/bin/bash

mkdir -p /etc/dhparam 2>/dev/null
FILE=`mktemp`

N=512
while [ $N -le 4096 ] ; do
  openssl dhparam $N -out $FILE && cat $FILE >/etc/dhparam/dhparam${N}.pem
  let N*=2
done

rm -f ${FILE}

I am using these ciphers that I hand-picked for maximum compatibility without any warnings in SSLLabs.

Code:

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;

I'm not saying there's anything wrong with virtubox ciphers.

virtubox · Jul 9, 2017

mr-wolf said:
Be really careful when choosing "includeSubDomains".
If you're hosting for others then chances are that one of your clients are hosting a plain http-site you are not aware of.
I was bitten, so just giving you a warning here.
If you're doing it server-wide then carefully examine the chances that this could happen to you too.

I also use the parameter "always".
Some sites will not show "A+" when testing it with "Qualys SSL Labs" if you omit this parameter.

@UFHH01 gave me the idea of creating a new key each week.

ln -s /usr/local/sbin/gen_dhparam /etc/cron.weekly/
cat /usr/local/sbin/gen_dhparam

Code:

#!/bin/bash mkdir -p /etc/dhparam 2>/dev/null FILE=`mktemp` N=512 while [ $N -le 4096 ] ; do openssl dhparam $N -out $FILE && cat $FILE >/etc/dhparam/dhparam${N}.pem let N*=2 done rm -f ${FILE}

I am using these ciphers that I hand-picked for maximum compatibility without any warnings in SSLLabs.

Code:

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;

I'm not saying there's anything wrong with virtubox ciphers.

My ciphers suite come from Mozilla SSL Configuration tool : Generate Mozilla Security Recommended Web Server Configuration Files
For a full security report, Mozilla observatory use several tools including SSLLabs, but it require more configuration to have a good score : Observatory by Mozilla

mr-wolf · Jul 9, 2017

Mine come from that site as well, but then I removed some ciphers which gave warnings.
Removing them turned some Windows XP browser unsupported, but these wouldn't work anyhow as it doesn't support SNI and all my https-sites need that.

Yours may be just as good, maybe even better.
I just know that mine are better than default and also better than ones I got recommended.
I had some complaints about a specific site not showing on a specific browser.
After I started using these ciphers I never heard any complaint anymore.

virtubox · Jul 9, 2017

mr-wolf said:
Mine come from that site as well, but then I removed some ciphers which gave warnings.

With the modern level ?
only the "old profile" use bad ciphers suite, no issue with the intermediate or modern profile. But it's also related to the certificate used. Some ciphers suite require newer openssl version and ECDSA certificates

mr-wolf · Jul 9, 2017

virtubox said:
With the modern level ?
only the "old profile" use bad ciphers suite, no issue with the intermediate or modern profile. But it's also related to the certificate used. Some ciphers suite require newer openssl version and ECDSA certificates

Check my previous message.
I edited it...

I went for maximum compatibility without sacrificing security.

I know other providers can sacrifice some compatibility as they just say to their clients that they should use more modern hardware/software.
We really can't.
I think I have a nice set now.

You could PM me to ask for a site.
Maybe you have a hint for improvement.

virtubox · Jul 9, 2017

mr-wolf said:
Check my previous message.
I edited it...

I went for maximum compatibility without sacrificing security.

I know other providers can sacrifice some compatibility as they just say to their clients that they should use more modern hardware/software.
We really can't.
I think I have a nice set now.

You could PM me to ask for a site.
Maybe you have a hint for improvement.

The only issue I previously had with ECDSA certificates (P-384) was with Android 7.0, which doesn't support properly ECC. But it doesn't impact android 6 or 7.1 mobile...
But with my current configuration, only very old browser are incompatible, and the most part because they doesn't support SNI.
If I keep TLS v1.1 currently, I do not want to use TLS 1.0 anymore.

Dukemaster · Jul 11, 2017

Sorry at all, but here it's necessary to write a lil more for various reasons.
Thanks for the suggestions and inspirations both of you @virtubox and @mr-wolf.
First I have to say clearly that my setup in the first two postings gave me A+ rating since beginning of this year. Even OS was changed by provider from Ubuntu 14.04 to 16.04. March/April. It was stable and well configured by the great never ending help of @UFHH01.
Now HSTS is not working. There are only few reason which could be responsible.
- Securing main/standard IPv4 (also Plesk) with a Letsencrypt certificate (expanded IP-Multi). This great goal could be responsible why HSTS doesn't work anymore) together with another change last weeks. I will write it in the bottom.
- Activated OSCP stapling.
- Last week I successfully made the setup to use own nameservers my only 1. server together with PLESK DNS, with three IPv4 (1 main/standard IPv4 only for webhosting, the 2 additional IPv4 only for both nameservers.
- Removing IPv6 from all webhosting accounts.
Exactly this could be the reason for HSTS.
Because until today nobody could tell me why it's impossible installing additional IPv6 (dedicated or shared) in PLESK. If you do it, after each reboot the whole apache and mostly nginx configuration will be destroyed. Other user have also the problem I read here. I gave it up.
And I have a feeling that there is a problem in the whole IPv6 configuration. There are less like nothing information on internet about this. I also think that the subnet 2001:8d8:966:e900::/56 has to be configured in PLESK or Ubuntu to make it possible to install correctly additional IPv6. But this is another problem/issue/question.
But HSTS doesn't work perhaps for the reason of trying to resolve something which is not configured properly.

virtubox said:
You can set the headers for HSTS directly in Apache/Nginx Settings (for ipv4 and ipv6) In Additional headers :

Sorry, @virtubox I don't understand what you mean. You wrote about apache/nginx setting, but by reading it I will only think about the "Settings for Apache and Nginx" in domain/subscription. With HTTP, HTTPS, Proxy setting, static files config., and with additional nginx directives. EXACTLY where I put the OCSP-stapling configuration in the bottom box additional nginx directives few weeks ago:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /usr/local/psa/var/modules/letsencrypt/etc/live/cosirex.com/fullchain.pem;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;

But your text can't refer this box, for format and other reasons. Perhaps, I think you mean another location, perhaps etc/nginx/conf.d/ where most config-files are located? But which file. perhaps a new one? I don't know. Perhaps you can give me more details.

I'm interested why you speak about IPv4/IPv6 in additional headers. Where, why and how?
I wish someone could tell how I examine my IPv6 environment. Everything is working fine, hosts, interface, until the point I start adding IPv6. Or in the other way around, the basic IPv6 configuration could have a basic problem. I think IPv6 has more influence (especially 1and1) as the usual main IPv4.
ok enough. I'm not able to examine without help.
Greets

Greets

virtubox · Jul 11, 2017

My headers are set in my domain Apache&Nginx settings > additional headers

It's working with IPv4 + IPv6 .
About IPv6, you have to use a single IPv6, but have you added DNS records for IPv6 ?

mr-wolf · Jul 11, 2017

Dukemaster said:
Sorry, @virtubox I don't understand what you mean. You wrote about apache/nginx setting, but by reading it I will only think about the "Settings for Apache and Nginx" in domain/subscription. With HTTP, HTTPS, Proxy setting, static files config., and with additional nginx directives. EXACTLY where I put the OCSP-stapling configuration in the bottom box additiona
But your text can't refer this box, for format and other reasons. Perhaps, I think you mean another location, perhaps etc/nginx/conf.d/ where most config-files are located? But which file. perhaps a new one? I don't know. Perhaps you can give me more details.

Yes, create a new file in /etc/nginx/conf.d/ that starts with aa00 (nginx parses these alphabetically) and define stapling there.
it will be server-wide then.

# cat /etc/nginx/conf.d/aa400_own_tweaks.conf

Code:

ssl_session_timeout         10m;
ssl_session_cache shared:SSL:50m;

ssl_dhparam /etc/dhparam/dhparam4096.pem;

add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
#add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains' always;
add_header Strict-Transport-Security 'max-age=15768000' always;

# cat /etc/nginx/conf.d/ssl.conf

Code:

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

But I got this from a reply in a thread you created
Resolved - How can I adjust HSTS in Plesk?

Are you using the "always" directive?
If one of the sites need authentication the SSLlabs test fails...
Just checked again and I'm still on A+

OCSP stapling is not required to get an A+ status on SSLlabs.

virtubox · Jul 11, 2017

mr-wolf said:
Yes, create a new file in /etc/nginx/conf.d/ that starts with aa00 (nginx parses these alphabetically) and define stapling there.
it will be server-wide then.

# cat /etc/nginx/conf.d/aa400_own_tweaks.conf

Code:

ssl_session_timeout 10m; ssl_session_cache shared:SSL:50m; ssl_dhparam /etc/dhparam/dhparam4096.pem; add_header X-Frame-Options SAMEORIGIN; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options nosniff; #add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains' always; add_header Strict-Transport-Security 'max-age=15768000' always;

# cat /etc/nginx/conf.d/ssl.conf

Code:

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

But I got this from a reply in a thread you created
Resolved - How can I adjust HSTS in Plesk?

Are you using the "always" directive?
If one of the sites need authentication the SSLlabs test fails...
Just checked again and I'm still on A+

In my opinion, HSTS headers should not be added in the global nginx configuration. It will apply HSTS on all websites hosted on the server.
You can add set HSTS headers for each domain configuration directly from the Plesk interface.

When you use Apache + Nginx , header should not be set twice and HSTS headers should be added in Apache configuration only.

mr-wolf · Jul 11, 2017

virtubox said:
In my opinion, HSTS headers should not be added in the global nginx configuration. It will apply HSTS on all websites hosted on the server.

Depends on your usage.
I have a server with only 2 websites.
On another server I indeed did not want to do it there.

There I gave the exact info in the domain settings "additional nginx directives"
You can't mix that.

virtubox · Jul 11, 2017

mr-wolf said:
Depends on your usage.
I have a server with only 2 websites.
On another server I indeed did not want to do it there.

There I gave the exact info in the domain settings "additional nginx directives"
You can't mix that.

Only if you have turned off Proxy mode on your domain.
Otherwise, HSTS headers have to be set in Apache Additional directives or Additional headers, and will be forwarded by Nginx

mr-wolf · Jul 11, 2017

nginx is handling the SSL connection either way.
If nginx is handling port 443 it is the endpoint for the SSL-connection.
Apache is not in contact with the outside world.

Maybe, just maybe, Nginx is clever enough to detect those Apache settings and "proxy" those too.
It still has to be done by Nginx.
Your statement that it has to be done in the Apache settings is still false. (edit: it can't even be done there if nginx is used)
Mine is in proxy mode and it (of course) uses the SSL directives I set for nginx.

If you turn off the proxy you just stop using Apache for that website and start using nginx for everything.
So it's not proxying for Apache, but is actually the webserver.

I have all my sites running Nginx as the proxy and Apache as the webserver.
The directives are working there as I expect them to.

[Edit]
I just tested if Nginx detects the HSTS settings in Apache if it is proxying for it.
It doesn't.
Apache settings do not influence the SSL-connection (which is to be expected).

Only in the first option (Nginx not in use) the HSTS-setting can be set in Apache. In all the other modes it has to be set in Nginx.
The third option is how most have it configured.

Only 1 process can listen to port 443. That's Nginx or Apache.
You can't "skip" Nginx for certain websites. You can merely turn on transparent proxy. Even then it will be Nginx handling the SSL

Nginx not used = Apache is listening on port 443 and handles everything
Nginx transparent proxy = Nginx is listening on port 443, but lets Apache handle all the content
Nginx in proxy mode = Nginx is listening on port 443 and can handle some content but lets Apache handle most
Nginx proxy off = Nginx is listening on port 443 and handles all content
Nginx transparent proxy = Nginx is listening on port 443, but lets Apache handle all the content

virtubox · Jul 11, 2017

mr-wolf said:
[Edit]
I just tested if Nginx detects the HSTS settings in Apache if it is proxying for it.
It doesn't.
Apache settings do not influence the SSL-connection (which is to be expected).

Have you removed the header from nginx before adding them in Apache ?
HSTS header set in Apache configuration are forwarded by Nginx, in proxy mode.

In proxy mode apache just use port 7080 for http and 7081 for https.
And if you add options in "Additional headers" , Plesk add them automatically in Nginx configuration if you are using proxy mode :

vhost nginx configuration :

Code:

server {
        listen [2001:41d0:d::443 ssl http2;

        server_name app.yoursite.tld;
        server_name www.app.yoursite.tld;
        server_name ipv6.app.yoursite.tld;

        ssl_certificate             /opt/psa/var/certificates/cert-EXddPz;
        ssl_certificate_key         /opt/psa/var/certificates/cert-EXddPz;
        ssl_client_certificate      /opt/psa/var/certificates/cert-xVkN6F;

        client_max_body_size 128m;

        proxy_read_timeout 300;

        root "/var/www/vhosts/yoursite.tld/app.yoursite.tld";
        access_log "/var/www/vhosts/system/app.yoursite.tld/logs/proxy_access_ssl_log";
        error_log "/var/www/vhosts/system/app.yoursite.tld/logs/proxy_error_log";

        location / {
                proxy_pass https://[2001:41d0:]:7081;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header X-Accel-Internal /internal-nginx-static-location;
                access_log off;
        }

        location /internal-nginx-static-location/ {
                alias /var/www/vhosts/yoursite.tld/app.yoursite.tld/;
                internal;
                expires "2592000";
        }

        location ~ ^/(plesk-stat|awstats-icon|webstat|webstat-ssl|ftpstat|anon_ftpstat) {
                proxy_pass https://[2001:41d0:d:]:7081;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header X-Accel-Internal /internal-nginx-static-location;
                access_log off;
        }

        add_header "Referrer-Policy" "strict-origin-when-cross-origin";
        add_header "Strict-Transport-Security" "max-age=31536000; includeSubDomains; preload";
        add_header "x-xss-protection" "1; mode=block";
        add_header X-Powered-By PleskLin;

        include "/var/www/vhosts/system/app.yoursite.tld/conf/vhost_nginx.conf";
}

Dukemaster · Jul 11, 2017

THANK YOU VERY MUCH for great help and discussion about this never ending story which always refers to our own special and total configuration and environment. What is the best for someone, could be the worst for his neighbour.
I tested both of your solutions and destroyed my whole nginx. But it's not your fault, it has to do that I don't use these additional dhparam.
To make a conclusion. I always followed @UFHH01 @IgorG @Lloyd_mcse @Peter Debik and lot of others related to Plesk Support Team tutorials and look strictly that it refers to my own configuration.

Sometimes the world turns the other way as it looks like!
@mr-wolf You had intersting hand selected ciphers. After I returned in the end back to my configuration like the last months with A+ but without OSCP stapling I tested your ciphers. YOUR ciphers are in the left side of the screenshot.
They are really not bad, but
they get less rating in SSLLABS, because they support less protocols. You looked too much on the red colored things. These are no errors. In this special case of handshakes RED MEANS GOOD. RED is better because its safer.
0,5% (375%) is not much less than 380 percent but it's a lil more secure.
BOTH sides, your ciphers and also the recommened ones by PLESK and @UFHH tested on the right side have A
Both tested with the same domain 5 minutes difference.

I already wish and hope to get a hint why OSCP stapling, I guess, turns me down from A+ to A? Or is it DNS related with only IPv4 clued own DNS servers.

It was your question @virtubox if I used only IPv4 or also IPv6.
According to the problem that it's always impossible to install properly additional dedicated IPv6 in PLESK (except the standard one) I realized the DNS only by IPv4. First I gave one domain the first new IPv4 as A-record and set the reverse mapping in IP Panel of 1and2.Then the ns1/ns2 subdomains in 1and1 were created by standard 1and1 nameservers, THAT is the goal and important thing. Then I changed the A-record of ns1/2 SUBDOMAINS of each domain to the same new additional IPv4 in subdomains which they their domain has also as A-record and therefor the glue was created, Then I created the ns1/2 and their new IPv4 A records also in PLESK. Works perfect, but took me 6 weeks horrible work..And it's my special masterpiece, lol, because the first time I did without any help still alone but got crazy by this. I write a tutorial in my board, because nowhere in whole Internet this 1and1/Plesk setup is documented.
But for hosting in Plesk I use the old main standard IPv4 I ever used for all 8 domains. Perhaps this is a mistake. I have no power to kill my brain by nameservers for months.

mr-wolf said:
I am using these ciphers that I hand-picked for maximum compatibility without any warnings in SSLLabs.

virtubox · Jul 11, 2017

Dukemaster said:
THANK YOU VERY MUCH for great help and discussion about this never ending story which always refers to our own special and total configuration and environment. What is the best for someone, could be the worst for his neighbour.
I tested both of your solutions and destroyed my whole nginx. But it's not your fault, it has to do that I don't use these additional dhparam.
To make a conclusion. I always followed @UFHH01 @IgorG @Lloyd_mcse @Peter Debik and lot of others related to Plesk Support Team tutorials and look strictly that it refers to my own configuration.

Sometimes the world turns the other way as it looks like!
@mr-wolf You had intersting hand selected ciphers. After I returned in the end back to my configuration like the last months with A+ but without OSCP stapling I tested your ciphers. YOUR ciphers are in the left side of the screenshot.
They are really not bad, but
they get less rating in SSLLABS, because they support less protocols. You looked too much on the red colored things. These are no errors. In this special case of handshakes RED MEANS GOOD. RED is better because its safer.
0,5% (375%) is not much less than 380 percent but it's a lil more secure.
BOTH sides, your ciphers and also the recommened ones by PLESK and @UFHH tested on the right side have A
Both tested with the same domain 5 minutes difference.

I already wish and hope to get a hint why OSCP stapling, I guess, turns me down from A+ to A? Or is it DNS related with only IPv4 clued own DNS servers.

It was your question @virtubox if I used only IPv4 or also IPv6.
According to the problem that it's always impossible to install properly additional dedicated IPv6 in PLESK (except the standard one) I realized the DNS only by IPv4. First I gave one domain the first new IPv4 as A-record and set the reverse mapping in IP Panel of 1and2.Then the ns1/ns2 subdomains in 1and1 were created by standard 1and1 nameservers, THAT is the goal and important thing. Then I changed the A-record of ns1/2 SUBDOMAINS of each domain to the same new additional IPv4 in subdomains which they their domain has also as A-record and therefor the glue was created, Then I created the ns1/2 and their new IPv4 A records also in PLESK. Works perfect, but took me 6 weeks horrible work..And it's my special masterpiece, lol, because the first time I did without any help still alone but got crazy by this. I write a tutorial in my board, because nowhere in whole Internet this 1and1/Plesk setup is documented.
But for hosting in Plesk I use the old main standard IPv4 I ever used for all 8 domains. Perhaps this is a mistake. I have no power to kill my brain by nameservers for months.

About nginx configuration, just remove additional configuration added and set back the default nginx ssl configuration :

Code:

ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

But your ciphers suite seems to be currently incorrect, When ssllabs display Server closed connection in red, that mean browser doesn't support configuration, but 10+ handshake_failure mean there is an issue with your cipher suite.
You can't score A+ with ssllabs without HSTS and OSCP stapling is not included on ssllabs at the moment.
Rating score parameters are available here : SSL Server Rating Guide · ssllabs/research Wiki · GitHub

Use Observatory by Mozilla for better security reports.
About IPv6 , I do not use DNS server in Plesk, so I could not tell you if your dns templates are correct.

mr-wolf · Jul 12, 2017

Dukemaster said:
I already wish and hope to get a hint why OSCP stapling, I guess, turns me down from A+ to A? Or is it DNS related with only IPv4 clued own DNS servers.

I don't have ipv6 and am on A+
It's the HSTS that gets me from A to A+
OCSP stapling is not necessary to get A+ on SSLlabs, but that should not stop you from using it.

I'm still not seeing others to start using the "always" parameter.
I was not getting A+ because that parameter was not there.
It does not happen with all sites, Especially if your site needs authentication it is needed.

@virtubox
No headers were forwarded to Nginx and HSTS-setting in Apache didn't change the Nginx behaviour.

Even if it did.
Why have it there?
Nginx is the one talking to the outside world server-wide. You speak of those site specific settings as if you can take nginx out of the connection train.
Nginx will always be in between the outside world and Apache. It does not shortcut for some specific domains.

So if your server-wide setting is using Nginx I can see no use of putting the parameters there.
The only reason I can think of is that you would want to be able to remove Nginx server-wide and still want those headers in place.

In my tests the addition of the headers to Apache did not make any difference.

But that was not what set this of.
You said that you MUST set HSTS in Apache if you are proxying.
That is not true.

I still haven't seen anything that suggests that Apache settings regarding the SSL connection on Apache are used in Nginx

[EDIT]
You speak of Plesk adding Apache headers to Nginx as well.
That's not the same as "Forwarding"
Why oh why put anything in Apache at all if you are using nginx????

Resolved HSTS doesn't work anymore

Regular Pleskian

Regular Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Regular Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Silver Pleskian

Regular Pleskian

Regular Pleskian

Regular Pleskian

Silver Pleskian

Similar threads