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

Help
1

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
2

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
3

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
4

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
5

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
6

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
7

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
8

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
9

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.

1 Like
10

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
11

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.

1 Like
12

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.

14

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
15

Thanks for sharing the changes that worked for you!

1 Like
16

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