4

I installed StartSSL on my web server which is running Linux Apache on CentOS 6.5. shaaaaaaaaaaaaa.com said

Nice. example.com has a verifiable certificate chain signed with SHA-2.

However Google Chrome on Debian 7.8 said

The connection is encrypted using AES_128_CBC, with SHA1 for authentication and ECDHE_RSA as the key exchange mechanism.

On the Debian box, I did

mkdir ~/StartComCerts
mv /etc/ssl/certs/StartCom* ~/StartComCerts

and the problem went away. However, expected clients to make changes to their computers is not a workable solution. So I purchased the GeoTrust QuickSSL Premium certificate from ssls.com. Then I went to https://knowledge.geotrust.com/support/knowledge-base and it said "Certificate is installed correctly". However, when I go my site using Chrome on Debian 7.8, I get the messages:

This site uses weak security configuration (SHA-1 signatures) so your connection may not be private.

and

The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.

I tested my site on www.ssllabs.com/ssltest/analyze.html. It rated my site with an A and said that my signature algorithm is SHA256withRSA. I went to shaaaaaaaaaaaaa.com said

Nice. example.com has a verifiable certificate chain signed with SHA-2.

I went to whynopadlock.com and everything checked out positively. I also tested with Chrome on another computer, running Windows 7, and got a green padlock with no error messages.

I don't know why I am getting the SHA-1 error on Chrome on Debian.

Edit - 2015-06-15

I also have an Sha-1 problem on some Windows systems. Below is the screen shot from Google Chrome on my home Windows system (left) and on my work Windows system (right). It seems to be using an Sha-1 cached certificate on different systems. I set up the intermediate certificate as per the instructions given by GeoTrust.

screenshot of ssl warnings

Edit:

I have a home business which is the purpose of my web site.

Improve this question
7
  • 3
    See groups.google.com/a/chromium.org/forum/#!topic/security-dev/… for probably the reason and how to solve the issue.
    – Steffen Ullrich
    Jun 15, 2015 at 5:27
  • 1
    I only skimmed that, after the first few messages, but I don't recall seeing anything that looked like a solution, except perhaps "don't use Debian". Which is a fine idea, of course, but if that's the answer, it ought to be a bit more explicit.
    – Michael Hampton
    Jun 15, 2015 at 12:13
  • Sorry about my slow reply. The discussion seemed to be more focused on the client side. Can I fix this problem on the server side? I seem to have a similar problem on different Windows systems as well. I have attached screen shots to my question. Thanks,
    – OtagoHarbour
    Jun 16, 2015 at 2:52
  • Are both systems Windows 7 and are they both fully up to date?
    – Natalie Adams
    Jun 16, 2015 at 3:22
  • 4
    Maybe if you didn't blank out the domain name it'd be a lot easier for us to check what's wrong.
    – noitsbecky
    Jun 16, 2015 at 13:50

2 Answers 2

Reset to default
5

The problem is that your Windows computer has Avast antivirus installed. Avast injects a SSL certificate between the website and Google Chrome. See "Avast web/mail shield" on top of the left image.

Google Chrome shows a warning on your computer since Chrome validates the locally spoofed certificate. Avast AntiVirus spoofs the SSL certificates so they can see and scan the SSL traffic. Scans like Qualys SSL labs will tell you the truth.

You can disable Avast Web/Mail shield and retry it in Google Chrome. That way, Chrome will validate the certificate that your server serves and not the injected/spoofed SSL certificate that Avast injects between your server and Google Chrome.

On the left image you're looking at the info about the Avast SSL certificate. On the right to info about your own GeoTrust SSL certificate.

I'm assuming you also use the Linux version of Avast on your Debian machine and that generates a similar situation as on the Windows machine.

Improve this answer
3
  • Indeed. Disabling Avast Web/Mail shield on my home system brought it into synch with my work system - same error messages. That certainly helps since my web server is at home. Thanks very much! It seems the problem is that the clients use a cached certificate, with SHA-1, instead of my new certificate with SHA-2. I tried changing the name of my intermediate certificate, configuring my web site to use the new name and restarting Apache. Unfortunately, that did not fix the problem. I don't have Avast on my Debian system. Thanks,
    – OtagoHarbour
    Jun 17, 2015 at 1:16
  • @OtagoHarbour did this answer your question?
    – Bob Ortiz
    Jun 24, 2015 at 18:32
  • It answered part of the question (about the difference between the two Windows systems) and was very helpful so I accepted the answer. I have the answer, for fixing the problem with Windows, above. The problem with Debian is still unresolved but I don't personally know anyone,apart from myself, who uses Debian.
    – OtagoHarbour
    Jun 26, 2015 at 1:09
1

The problem ist, that your certificate uses SHA1 as signature alogrythmus. If your certificate actually uses SHA2, check all the intermediate (and root) certificates in your chain. Every single certificate has to use SHA2.

SHA1 is old (weak) technology and should not been used anymore. Most PKI providers have both possibilities. Simply download SHA2 chain certs and upload them to your server. Then the problem will be solved.

As you are using an SHA2 cert (like seen above) the problem as to be on one of the intermediate certificates. Check them all for SHA1 and get the SHA2 ones instead.

Improve this answer
4
  • My certificates are new from GeoTrust. I think it is a problem with client machines using cached certificates. I could fix it for my client machines but I do not want my visitors to have to do that. Thanks,
    – OtagoHarbour
    Jun 17, 2015 at 1:23
  • Both certificates use security algorithm SHA256withRSA.
    – OtagoHarbour
    Jun 17, 2015 at 1:31
  • On your printscreen you can see, that the one certificate on the right picture is using SHA1. Quote: "The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism."
    – valentin-laett.ch
    Jun 18, 2015 at 17:44
  • It wasn't the certificate. It was the message authentication. I have found a solution and provided a link in a comment above.
    – OtagoHarbour
    Jun 20, 2015 at 15:07

Not the answer you're looking for? Browse other questions tagged .