Site 'Not secure' warning even though the certificate is valid

My domain is: media.fab.plus

Here is a really simple test to demonstrate the issue.
The pic
When I load the following URL,
https://media.fabcrm.com/test.html

It produced the expected output fine, BUT Google Chrome complains the site is ‘Not secure’.
The digital certificate appears to be perfectly fine.
However, some research suggests this could be due to there being a certificate in the path using an SHA1 algorithm.
THE CERTIFICATE WAS PERFECTLY FINE UNTIL YESTERDAY.
Can you help?

My web server is (include version): IIS7
Windows Web Server 2008 R2.
Version 6.1.7601 Service Pack 1 Build 7601

The operating system my web server runs on is (include version):
Windows Web Server 2008 R2.

1 Like

It might be because my Chromium isn’t the latest version, but I’m seeing a green padlock without any error? Do you have a literal copy of the error? Or perhaps a screenshot?

Also, there are no SHA1 algorithms in the Let’s Encrypt certificates. Perhaps only the root certificate from IdenTrust uses the SHA1 algorithm, but this isn’t really an issue for root certificates.

1 Like

I am using Chrome Version 83.0.4103.116 (Official Build) (64-bit)
Getting lots of visitors complaining they cannot access the site. It is affecting all our sites which are using the same Let’s Encrypt certificates. The sites are located on different servers too! Plus they are different domains. So, are you suggesting you can visit https:media.fabcrm.com/test.html on Google Chrome and the site reports perfectly fine and no security issues?
There really isn’t a lot to go wrong here!!!
certificate-issue

1 Like

Well, if you mean by “no security issues” I’m not getting any warning up front and the padlock is green, yes. (Although when I click on said green padlock, I see the same message you’re seeing.) Note, like I said, I’m using an older version (81.0.4044.122). Compiling Chromium from scatch is a #)($*)#( and takes a whole night or even longer, so I’m not very up to date unfortunately.

However, if I’m looking at the “Security” tab of the Inspector window, my Chromium does notice some issues (which aren’t apparent, until you’re looking for them in my version!):

Connection - obsolete connection settings

The connection to this site is encrypted and authenticated using TLS 1.0, ECDHE_RSA with P-256, and AES_256_CBC with HMAC-SHA1.

* TLS 1.0 is obsolete. Enable TLS 1.2 or later.
* AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.

This isn’t a certificate issue though, but a webserver configuration issue. Please use Google or IIS documentation on how to change those settings in IIS.

1 Like

Okay, thanks. I compared another certificate we have in cpanel on litespeed and apart from the domain name, they were identical. So the only issue appears to be potentially the server. Your check is beyond me, so thank you. I will research this and see if I can figure out what changed yesterday. We have not applied any server patches recently either.

I suspect this is not going to be entirely straightforward.

1 Like

I would recommend to also search for perhaps any changes Google made in their requirements for a green padlock in Chrome/Chromium: perhaps they modified a requirement in the latest versions of the browser.

1 Like

I did find an issue that suggested any certificate in the path since yesterday must not use SHA1 encryption. Given the very root certificate is SHA1, this led me to conclude it might be the issue.
However, other sites using the same type of certificate are perfectly fine. Thus, suggesting it is the
web server somehow. I am at a loss as to how to why this started yesterday, and we are getting more
support issues from customers coming across the same issue.

1 Like

Interesting, I visited the same page from another machine running Google Chrome Version 84.0.4147.89 (Official Build) (64-bit)
No issues. Site secure.

1 Like

Hi @FABIT

that’s wrong, the SHA1 of the root certificate isn’t a problem. Because it’s a root certificate.

It’s your configuration and your too old Windows 2008.

Download IISCrypto and try to activate Tls.1.2.

That may work with Windows 2008.

The

AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.

you can’t fix, that’s not supported.

Windows 2012 - you can use an EC certificate.

2 Likes

Sorry, but elliptice curve (EC) cryptography for authentication has nothing to do with the GCM mode of operation for the symmetric key cyper AES.


@FABIT You might also be interested in the fact http://media.fabcrm.com/test.html (HTTP) doesn’t automatically redirect to the HTTPS protocol.

1 Like

They have. Windows 2012 has some GCM Cipher suites working with EC. But there are no GCM Cipher suites with RSA.

Ssllabs changed the ranking, my site (that time Windows 2012) had B, I’v switched to EC, A again.

PS: That’s the reason it’s impossible to resolve that GCM problem with Windows 2008. There is no Cipher.

2 Likes

That’s totally not something I would have distilled from your words, sorry. Perhaps a little bit more explanation would be in order when saying seemingly contradictory stuff like that.

Hello,

One of my older production servers had this issue come up today as well on Chrome 84. The error listed here describes the problem and is visible when I access your server:

Chrome recently started blocking anything older than TLS1.2

Please ensure all your content is loaded over TLS1.2, the primary webpage as well as any scripts loaded after the fact.

Edit: Please ensure you click the advanced button, as this gives you useful diagnostic data. You can sometimes click the grey error text as well to reveal additional data (not in this case)

Edit 2: The firefox web browser also gives the same diagnostic data.

Imgur

2 Likes

Thank you everyone for your input.

I made the following registry updates to Windows Server 2008 R2 registry.
These registry keys fixed the problem, and enabled the site to go from F to A on ssllabs.com

Copy the following to a text file and save as ‘UpdateSecurityProviders.reg’

==== FILE START ====
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
“Enabled”=dword:00000000
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
“Enabled”=dword:00000000
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
“Enabled”=dword:00000000
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
“Enabled”=dword:00000000
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
“DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
“DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
“ServerMinKeyBitLength”=dword:00000800

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
“Enabled”=dword:00000000
=== FILE END ===

1 Like

Thanks for sharing the changes that worked for you!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.