I get the error missing HSTS header with my https:// site.
Any help as to how to correct this issue? Thanx
Hi @snogge
it's your first certificate (see your CT-log entries).
So you shouldn't add a HSTS header.
Wait, if the next one or two renews are correct.
Then you can add a HSTS header.
If you have a HSTS-header, users can't create an exception if your certificate is invalid or expired.
So a HSTS header requires an always working certificate.
You have Grade T, N and I you should fix. Minimal your Grade N + HSTS is terrible.
Thanx for your reply!
I don’t really understand. Are my certs working or not? I will work on my grades
Just to clarify - I have removed the http access, and I am currently only running the https://klimatfokus.nu, so i havent certified the https://www.klimatfokus.nu
That's bad. A public visible website should always have an open and working port 80 with a redirect http -> https. Most users start with http, so your site doesn't answer.
That's bad too. A domain should always have a www version and a correct redirect not-preferred version -> preferred version.
Some users add always www, some users add never www. Both should see the same result.
So a www DNS entry, a working website and a correct certificate are required.
okay thanx @JuergenAuer , I’ve reinstated the http access to both www and non-www. And they should be pointing to the https instead.
I also tried adding the cert to cover the www too, but it gets an error Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors.
Ive also addressed the “C Error - no preferred version www or non-www” in google search console to prefer the non-www.
Good: Now your non-www-vHost uses the correct certificate:
CN=klimatfokus.nu
18.05.2019
16.08.2019
expires in 90 days
klimatfokus.nu, www.klimatfokus.nu - 2 entries
Not so good. Your www-version doesn't use it. Perhaps that's another vHost.
What says
apachectl -S
Perhaps add a
ServerAlias www.klimatfokus.nu
to your non-www-vHost.
That has nothing to do with Google. Your server must have a correct redirect https + not-preferred -> https + preferred. See other domains with Grade E / D / C (wrong) and Grade B / A (correct).
As mentioned, you’ll want to respond to both www.klimatfokus.nu and to klimatfokus.nu, while making only one the preferred version. There are various reason to make the version with www preferred, so I’ll go with that, but you can flip it if you want.
Currently, your server responds on both www.klimatefocus.nu and on klimatfokus.nu, so you’re in a pretty good position. Just change the configuration for klimatfokus.nu so it permanently redirects to www.klimatfokus.nu. You’re using Apache, so that’s just Redirect permanent / http://www.klimatfokus.nu/. (Once you set up TLS, this is going to change a bit, but do one step at a time so you’ll know where the problem is if something doesn’t work.)
Once you’ve set up a preferred name, you can get TLS working. The certificate that klimatefokus.nu currently presents has both www.klimatfokus.nu and klimatfokus.nu as SANs, so you can use the certificate you already have for both; just configure www.klimatfokus.nu to return that certificate instead of the localhost.localdomain self-signed one.
At this point, https://www.klimatfokus.nu will work, but http://www.klimatfokus.nu will not redirect to it. For this bit, you want your server ready to respond to four possible URLs:
- http://kilmatfokus.nu, which should redirect to https://klimatfokus.nu
- https://klimatfokus.nu, which should redirect to https://www.klimatfokus.nu
- http://www.klimatfokus.nu, which should redirect to https://www.klimatfokus.nu
- https://www.klimatfokus.nu, which should be the actual site.
This way, you’ll be able to respond appropriately regardless of whether or not users include https:// or www.
At this point, you’ve fixed several of the problems currently reported:
- Error - no preferred version www or non-www: www is now the preferred version.
- fatal error: http result with http-status 200, no encryption: HTTP versions will redirect (status 301).
- Error - more then one version with Http-Status 200: This is basically the two previous issues combined into one. They’re fixed, this is fixed.
- Error - Certificate isn’t trusted, RemoteCertificateNameMismatch, RemoteCertificateChainErrors: This is a problem with https://www.klimatfokus.com, which currently uses a self-signed certificate for localhost.localdomain. You’ve reconfigured the server to use a real certificate, so this goes away.
Once this is set up, make sure there aren’t any other issues that might make HSTS site-breaking. (If you’re not sure that you’re safe, ask. As mentioned previously, making sure you can successfully renew your cert is a good minimum check.) Then you can configure Apache to send HSTS headers. Generally, you want the header on the raw domain and on www (and on any other subdomains that support TLS) sent only over TLS, starting with a low expiration time (around 30 seconds when you’re startting) and slowly ramping up to a year. Once you’re sure that all of your subdomains support TLS, add in the includeSubDomains token. Once you’re really sure that you’ll never back out of this, you can add the preload token and submit your site for preloading. (Do not add the preload token until you’re ready for your site to be preloaded.)
2 Likes
Thank you so much @maxh for this detailed info, I’m very grateful for that!
I think I’ve made progress thanks to you. Now it seems my server is answering and redirecting as you mentioned. Please have a look: https://check-your-website.server-daten.de/?q=klimatfokus.nu
Now it seems that SHA1 is the issue. But as far as I know, my ssl doesn’t allow that? Which protocols should I reject?
Thanx again both of you
Please read
O Old connection: SHA1 as Hash Algorithm is deprecated. Switch to SHA256 or SHA384. If your certificate has SHA256, check if there is an old Firewall or something else, that supports only SHA1. Update that component.
It's not a problem of your certificate, it may be a problem of another component. Perhaps outside of your server.
A Letsencrypt certificate normally doesn't produce that error message. So it's an old firewall, router or something else.
Either of the two “strong ciphers” options in the middle should work. You can also consider the Mozilla configurations. In either case, you should enforce cipher order. For stronger security, you should also seriously consider rejecting TLSv1.0, and probably TLSv1.1.
Thank you, I changed it accordingly
Hmm I have no clue where that comes from…
My router is modern, ASUS RT-AC66U with latest firmware.
The problem could be on the server. In webmin I can find “FirewallD” which is not installed. I can also find “Linux Firewall” which is active with ipv4, but No iptables(6) bootup action was found, indicating that the IPtables package is not installed on your system. Could that be the fault?
Checked your domain via
that's bad.
You have a lot of weak Cipher. Looks like this is another reason to downgrade the Hash algorithm.
TLS 1.2 (server has no preference)
TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f ) WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA ( 0x33 ) DH 2048 bits FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013 ) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c ) WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 ( 0x67 ) DH 2048 bits FS WEAK 128
TLS_RSA_WITH_AES_128_GCM_SHA256 ( 0x9c ) WEAK 128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 ( 0x9e ) DH 2048 bits FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 ) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ( 0xc02f ) ECDH secp521r1 (eq. 15360 bits RSA) FS 128
TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35 ) WEAK 256
That may be the problem.
I must update my error message.
Done - now there are additional informations:
Old connection: SHA1 as Hash Algorithm is deprecated. Switch to SHA256 or SHA384. If your certificate has SHA256, first check your domain via ssllabs.com and update weak Cipher Suites. If that doesn't help, check if there is an old Firewall / router or something else, that supports only SHA1. Update that component.
1 Like
Thanks for the additional information.
My ssl config looks like this
But in Allowed SSL ciphers, I listed the ones in Mozilla configurations - modern: 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
But the SHA1 still prevails - Nothing I change seem to change that…
My score on ssllabs.com gives me a Score “B” with weak ciphers still. Maybe this wont be a problem? Since i wont handle any log in info or any other vurnable user data from anyone?
Any how I cant seem to move forward on this SHA1 issue
A Grade B without Forward Secrecy is a problem.
It's a greater problem then the SHA1 phenomen.
If the traffic is saved and your server comprimised, the traffic can be decrypted.
With Forward Secrecy it's impossible.
So fix that Grade B.
PS: You have 6 active certificates, two created today - https://check-your-website.server-daten.de/?q=klimatfokus.nu
| CertSpotter-Id | Issuer | not before | not after | Domain names | LE-Duplicate | next LE |
|---|---|---|---|---|---|---|
| 921726979 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-20 10:46:12 | 2019-08-18 10:46:12 | klimatfokus.nu, www.klimatfokus.nu | ||
| 2 entries | duplicate nr. 4 | |||||
| 921413238 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-20 06:44:47 | 2019-08-18 06:44:47 | klimatfokus.nu, www.klimatfokus.nu | ||
| 2 entries | duplicate nr. 3 | |||||
| 918243369 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-18 07:21:36 | 2019-08-16 07:21:36 | klimatfokus.nu, www.klimatfokus.nu | ||
| 2 entries | duplicate nr. 2 | |||||
| 917043841 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-17 14:11:29 | 2019-08-15 14:11:29 | klimatfokus.nu | ||
| 1 entries | duplicate nr. 2 | |||||
| 915386386 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-16 16:00:25 | 2019-08-14 16:00:25 | klimatfokus.nu, www.klimatfokus.nu | ||
| 2 entries | duplicate nr. 1 | |||||
| 915317695 | CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US | 2019-05-16 15:06:23 | 2019-08-14 15:06:23 | klimatfokus.nu | ||
| 1 entries | duplicate nr. 1 |
As written. It’s not a certificate problem.
Use one certificate 60 - 85 days, then create the next.
this is what apachectl -S says
and when I run openssl s_client -connect localhost:443, this is what i get:
it says that secure negotiation IS supported, and using TSLv1.2. Isn’t that what i wanted?
You have to fix your Ssllabs - Grade B - and add Forward Secrecy.
That has nothing to do with your vHost-configuration. There
TLS_RSA_WITH_AES_128_CBC_SHA (
0x2f) WEAK
is your SHA (instead of SHA256).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.