Certificate error

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

lmk

Member
Dec 11, 2013
128
20
18
Hi @Patrick

There is an error with Google Canary and the length of validity on the forums.servethehome.com certificate.

It blocks access and does not seem to allow an exception to continue to the site.

The problem started this morning and it appears it is as a result of a recent update to Google Canary and the 4-5 year expiration of the certificate.

The error is below:

-----
Your connection is not private

Attackers might be trying to steal your information from forums.servethehome.com (for example, passwords, messages, or credit cards).

Advanced

NET::ERR_CERT_VALIDITY_TOO_LONG
----
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
Hi @Patrick

There is an error with Google Canary and the length of validity on the forums.servethehome.com certificate.

It blocks access and does not seem to allow an exception to continue to the site.

The problem started this morning and it appears it is as a result of a recent update to Google Canary and the 4-5 year expiration of the certificate.

The error is below:

-----
Your connection is not private

Attackers might be trying to steal your information from forums.servethehome.com (for example, passwords, messages, or credit cards).

Advanced

NET::ERR_CERT_VALIDITY_TOO_LONG
----
Hmmm.... interesting. I wonder if anyone else is getting this error.
 

Alfa147x

Active Member
Feb 7, 2014
189
39
28
I'm on Chromium Version 38.0.2125.111 (290379)

I'm not experiencing anything funky

Edit: I'm on OS X
 
Last edited:

lmk

Member
Dec 11, 2013
128
20
18
Google Canary Version 41.0.2215.0 canary (64-bit) and Version 41.0.2216.0 canary (64-bit) showing same behaviour.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
Thanks @Entz !!!! That saved me hours of trying to fix something due to a chrome daily bug. It is certainly the SHA-1 related check going off at the wrong time.
 

lmk

Member
Dec 11, 2013
128
20
18
@Patrick I am glad to help :)

If it is your site's certificate, then the quick/sledgehammer solution would be to get a shorter certificate (which is, as you said, ridiculous).

Unfortunately, it is not clear if it is only that particular certificate.

I just took some time to try and get some answers...

1) I confirmed your certificate shows as SHA-256. However, taking a look through the chain, I wonder if the root being SHA-1 is the culprit.

imgur: the simple image sharer

2) It may be a continuation of Google et al driving for better security (re: sunsetting the older SHA-1, etc).

Chromium Blog: Gradually Sunsetting SHA-1

So, given that I am using a bleeding edge version, I may be the first to see what will happen with the rest of the browsers.

My Canary is living up to it's namesake :)
 

lmk

Member
Dec 11, 2013
128
20
18
@Entz just read through the filed bug. I did see a mention that it may be a SHA-1, found along the chain, too.

Interested to see what it turns out to be.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
@Entz just read through the filed bug. I did see a mention that it may be a SHA-1, found along the chain, too.
SHA-1 is OK for CA root servers. Should be fine. The Qualsys checker penalizes if you do not use the newer version (and hence why @eva2000 gave me a heads-up to change awhile back.)
 
  • Like
Reactions: eva2000

Entz

Active Member
Apr 25, 2013
269
62
28
Canada Eh?
@Entz just read through the filed bug. I did see a mention that it may be a SHA-1, found along the chain, too.

Interested to see what it turns out to be.
Indeed it will. Really would hate for sites that bought longer Certificates (cost savings) to suddenly get black listed because of a date issue.
 

lmk

Member
Dec 11, 2013
128
20
18
Update:

"There was a bug in the code that caused this warning to be triggered more aggressively than intended. It's being fixed."

Looking further, it seems:

"The 39 month check kicks in since the hardcoded dates are set in seconds, while
start is in microseconds since the epoch. Adding 6 zeros to the hardcoded dates
should fix the issue."​
 
  • Like
Reactions: Entz and Patrick

eva2000

Active Member
Apr 15, 2013
244
49
28
Brisbane, Australia
centminmod.com
SHA-1 is OK for CA root servers. Should be fine. The Qualsys checker penalizes if you do not use the newer version (and hence why @eva2000 gave me a heads-up to change awhile back.)
yup SHA1 for CA root is fine ... SSLlab test looks fine, just you have to update openssl system package and Centmin Mod Nginx static OpenSSL for TLS_FALLBACK_SCSV support as well SSL - POODLE attacks on SSLv3 vulnerability and Nginx - Updating OpenSSL 1.0.1j for Centmin Mod
Code:
Downgrade attack prevention    No, TLS_FALLBACK_SCSV not supported (more info)
 

TangoWhiskey9

Active Member
Jun 28, 2013
402
59
28
Is this all just because you're using the daily? I'm not having the problem but I don't want to update if it's present.
 

lmk

Member
Dec 11, 2013
128
20
18
If you are using Canary, either keep the version you have (that is working) or update to the one released with the fix (41.0.2217.0).

I do not update daily and it only updated (which happened to be exactly when the break was released) when restarting my computer.