15

We run a website over HTTPS with a wildcard certificate from Positive SSL.

Today, when I opened Google Chrome (v. 42.0.2311.90 m) and navigated to the site, I noticed a red cross through the https part of the URL in the address bar. When I click on it, I get this:

SSL information

Can anyone explain what is going on here? Should I get a new certificate from another issuer?

Improve this question
1

3 Answers 3

Reset to default
16

Google blogged about flagging Certificates using SHA-1 here -> Gradually sunsetting SHA-1

There's no reason to get a new certificate yet as Chrome won't be actually blocking the certificate just treated as “secure, but with minor errors”, I believe that some issuers are offering to reissue certificate but as always, YMMV.

Improve this answer
5
  • 8
    Thanks. Well, I'm afraid it doesn't look very trustworthy to users now with that red line through HTTPS, so I'll contact PositiveSSL and look at some alternatives.
    – Knelis
    Apr 16, 2015 at 8:31
  • 9
    I was able to get the cert re-issued with SHA-2.
    – Knelis
    Apr 16, 2015 at 9:33
  • 3
    Actually, there is nothing wrong with SHA-1 certificates yet. Google decided to pre-emptively build this into Chrome. It would've been the smart move to start these warnings for the same cutoff date as Microsoft does (1 January 2017), but these two are not the best of friends it seems.
    – user13695
    Apr 16, 2015 at 12:55
  • 3
    @JanDoggen Google is using the same cutoff date, just in a different way. They are not warning against all SHA1 certificates, just relatively new ones that will not expire before 1/1/2017, which if you ask me is a pretty neat way to get this issue solved before 1/1/2017 (instead of suddenly flipping the switch). Honestly, I think the way they build it up from Chrome 39 to 41 and showed different information based on expiry date is extremely well considered.
    – David Mulder
    Apr 16, 2015 at 13:46
  • 4
    @Knelis: "it doesn't look very trustworthy" - well, that's the point.
    – user2357112
    Apr 16, 2015 at 18:32
10

You don't need to get another new certificate. In order to resolve this issue, you need to just reissue your certificate with SHA-2 signature. That's it.

Improve this answer
-4

Your website is secured with the SHA-1 algorithm.

The SHA-1 algorithm is now outdated and Google Chrome & other web browsers have already quit their support for it. The lower hash value and key length lets hackers crack the website easily.

Chrome 38.x users see the website as secured without any warning message, but Chrome 39, 41, 42, .... users will see this red cross error (Affirmatively Insecure).

Migrate from SHA-1 to SHA-2

You don't need to buy a new SSL certificate to troubleshoot this warning, just contact your SSL Certificate vendor or certificate authority to reissue your certificate.

Once you reissue your certificate, create a new CSR and re-install the SSL certificate on your server.

** Make sure you generate the new CSR with SHA-2 as encryption **.

Improve this answer
6
  • 3
    "Lower hash value and key length" has nothing to do with SHA-1's weakness, and it's also not related to how easy it is to "crack" an existing cert. The risk with SHA-1 is that there are cryptanalytic attacks (i.e. not brute-force) that allow an attacker to create two things with the same hash (they must control both things; this attack doesn't let them match the hash of your preexisting certificate). The actual risk is that an attacker could create two colliding certificates, one legit and one not, submit the legit one to the CA, and then put that signature on the not legit one.
    – cpast
    Apr 16, 2015 at 14:05
  • 3
    Citation needed for "lets hackers crack the website easily". I'm not aware that any of the theoretical attacks on SHA-1 can actually be practically used to break SSL encryption at this time, much less "easily". It's also not accurate that Chrome has "quit their support for it": they have announced that they will phase it out in a couple of years.
    – Nate Eldredge
    Apr 16, 2015 at 14:56
  • @cpast: As a point of clarification, the problem is that a CA who signs a certificate has no way of knowing that's the only certificate being signed, and someone receiving a "signed" certificate has no way of knowing whether the CA knowingly signed it, or thought it was signing something totally different?
    – supercat
    Apr 16, 2015 at 16:30
  • @supercat That is correct. This is why collision-resistant hashes are so useful -- they make it so an attacker can't produce two certificates with the same hash, so they can't produce two things where the sig from one can be applied to the other. The problem with SHA-1 is that there are much-faster-than-brute-force ways to produce collisions.
    – cpast
    Apr 16, 2015 at 17:36
  • @cpast: Could one also deal with collision issues by requiring that the person supplying the data to be signed must leave a certain amount of space at the beginning for random data supplied by the signatory? Would doing such a thing whenever practical be helpful in guarding against future attacks of that type?
    – supercat
    Apr 16, 2015 at 17:42

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