New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 475745 link

Starred by 9 users

Issue metadata

Status: WontFix
Owner:
Slow until 19 Oct 2018
Closed: Apr 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Major vendor certificates violating 39 month validity limit, triggers NET::ERR_CERT_VALIDITY_TOO_LONG error

Reported by j...@molomby.com, Apr 9 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.68 Safari/537.36

Steps to reproduce the problem:
1. Visit https://tasks.molomby.com/ (in Chrome 42 or later)

What is the expected behavior?
Site loads with a happy green padlock.

What went wrong?
An error screen is shown:

"Your connection is not private

Attackers might be trying to steal your information from tasks.molomby.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_VALIDITY_TOO_LONG

You attempted to reach tasks.molomby.com, but the server presented a certificate whose validity period is too long to be trustworthy."

The padlock icon is crossed out. Clicking it yields: 

"The server certificate has a validity period that is too long."

Did this work before? Yes Version 41 and earlier accept certs with long validity periods; limit is due to new guidelines

Chrome version: 42.0.2311.68  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 17.0 r0

The certificate currently installed on https://tasks.molomby.com was reissued a few days ago by RapidSSL (via ssls.com). It's validity period is 2015-04-07 08:57:25 GMT to 2018-07-09 07:00:18 GMT (about 39 months + 2 days).

Earlier this year changes were made to Chrome to bring it into line with the latest CA/Browser Forum guidelines (https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf), which state:

> CAs SHALL NOT issue certificates with validity periods longer than 39 months.

The relevant commit, as far as I can tell, is here..

  https://chromium.googlesource.com/chromium/src/+/4867d6cc021aca57e5a327b7ca8ed365485c0caa

Specifically, the HasTooLongValidity() function, lines 626-670 in /net/cert/cert_verify_proc.cc.

Although this is clearly a problem with the CA, in correspondence with me they've declined to address the issue..

> .. we could not find any official information as to major browsers marking certificates with 39+ months validity as insecure.

> .. hopefully it will be fixed by Google in the next stable version release.

Blah blah etc.

So RapidSSL are in violation of the CA/B guidelines but they're a fairly large CA (owned by GeoTrust/Verisign/Symantec whatever). Given how many users may be affected, is there no room for leniency in the implementation?

I've been unable to find any official recommendations on how "months" should be calculated with regards to validity periods. It's possible other CA's will also calculate 39 months "differently" while Chromes interpretation is quite strict.

Related issues?

* https://code.google.com/p/chromium/issues/detail?id=102949
* https://code.google.com/p/chromium/issues/detail?id=119213
 

Comment 1 by j...@molomby.com, Apr 9 2015

I'll try and leave the current (new but invalid) certificate online at tasks.molomby.com and will update this thread if it changes.

Comment 2 by rsesek@chromium.org, Apr 10 2015

Cc: sleevi@google.com
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security -OS-Windows Type-Bug OS-All Cr-Internals-Network-SSL Cr-Security
Owner: palmer@chromium.org
Status: Assigned
Moving out of the security vulnerability queue and assigning to palmer@, who authored 4867d6cc021aca57e5a327b7ca8ed365485c0caa.
Marking this as WontFix.

I repeatedly told CAs this was coming and that Chrome would be enforcing checks.

Similarly, with Mozilla we have begun tracking Baseline Requirements violations by CAs as part of an ongoing effort to restore and preserve trust in the system, and to help inform customers when their CAs may be intentionally or unintentionally causing issues for them.

I'm marking this WontFix as CAs have had three years to fix their systems, and this check only became an issue for new certs issued on or after April 1.

Comment 4 by rsesek@chromium.org, Apr 10 2015

Cc: -sleevi@google.com rsleevi@chromium.org
Status: WontFix
(WontFixing for real)

Comment 5 by j...@molomby.com, Apr 13 2015

For what it's worth I completely agree with this position. 

Incidentally, I've had the certificate reissued again today and the new one's valid (tested in 42.0.2311.82 beta-m (64-bit) and 44.0.2367.0 canary (64-bit)).

Comment 6 by palmer@chromium.org, Apr 13 2015

Oh, good, I'm glad you were able to get a reissue!

Comment 7 by Deleted ...@, Apr 16 2015

We have a wildcard cert issued in 2013 and we're experiencing this same issue.

https://admin.openhospitality.com/login.aspx

this is not good, what went wrong here? We have not heard from our CA's that this was coming...
The CA you got your certificate from fully participated in the design and development of these standards, as well as setting their effective date. However, they decided to delay implementing the requirements beyond the agreed upon date, and as a result, issued certificates that don't comply to the agreed upon requirements.

Comment 9 by Deleted ...@, Apr 16 2015

thanks for the quick reply. we're getting it re-issued through godaddy and testing an updated SHA2 version now.

Comment 10 Deleted

Comment 11 by Deleted ...@, Apr 17 2015

Also hit the same problem while renewing a RapidSSL/GeoTrust certificate.

Their answer so far :
"This is a known issue in our system.
We have escalated the issue to our engineer team already and they are working on it now."

The renewal was prompted by the degraded UI displayed by Chrome 42 when using long-lived SHA-1 certificates (http://googleonlinesecurity.blogspot.fr/2014/09/gradually-sunsetting-sha-1.html).
Needless to say, the concomitance of those 2 issues in the same Chrome release is quite unfortunate.

Hopefully, CA will fix this before my original certificate gets below 39 moths of remaining lifetime.

Comment 12 Deleted

Comment 13 Deleted

tlewinson [comments deleted]: Please try to keep the comments civil. Thanks!
I'd like to add in that the issue is definitely on the RapidSSL/GeoTrust end.  The combination of SHA-1/Cert length being applied at the same time kind of sucks, but I get it.

I ended up cancelling my certificate--which I'm *really* not happy about--and reissuing.  I figure it'll be quicker to get my customers a resolution that way and hope for a credit than try to fight against a reasonable standard implementation.

Comment 16 by Deleted ...@, Apr 24 2015

I have Chrome 42 on OS X, 42.0.2311.90 (64-bit), and it's not complaining about a 5 year cert issued after April 1, 2015. Did this change get released? The CA is an internal CA, not sure if that matters.
cgscott413: Correct, the policy only applies to publicly-trusted issuers. See line 282 in https://codereview.chromium.org/724543002/diff/160001/net/cert/cert_verify_proc.cc: before checking if the validity is too long, it first checks if the root issuer is "known" (public).
Can anyone tell me why this cert is failing?  
https://www.funeral.money/Login.aspx

valid from 4/21/2015 - 7/21/2018 is 39 months by my calculation.

My machine shows it as 4/20/2015 9:14:28 AM EDT to 7/21/2018, 9:50:36 PM EDT. That's still over 39 months by a bit more than 12 hours.

(Looking at the code, we don't actually count partial hours or minutes or whatever, so we'd normally incorrectly fail to flag this. But it happens to use UTC. In UTC, the second one lands at 7/22, so we flag this as too long, correctly.)
FWIW, it doesn't get treated as valid too long on Mac. (See screenshot: PDT.)
Screen Shot 2015-04-27 at 9.38.32 AM.png
168 KB View Download
That's bizarre... that code really shouldn't be platform-dependent or timezone-dependent (it's always using UTC).
Yeah; follow-up in a separate bug though :)
Filed  issue #481573 . The problem is that the certificate isn't marked as chaining up to a known root, so this check gets disabled.
Ok, I see now that I'm going to have to tell Entrust that they have a bug in calculating 39 months, but if the time portion can make the validity period fail because of UTC, then those dates on the general tab where it shows the validity period should be displayed in UTC as well...  just sayin..



Comment 25 by Deleted ...@, Apr 28 2015

In my mind there's nothing wrong with having a certificate be good longer than 39 months so long as it doesn't use deprecated security protocols such as SHA1.  But we get a couple of Google geniuses who declare "THIS IS HOW IT SHALL BE" and thusly, it is.

Nobody ever asked me if it was ok to increase my workload to have to change out certs more often, but whatever.
While I appreciate the complement, we're far from geniuses, and we also aren't the ones who set this up. Indeed, this was discussed for several years, and finalized in 2011. There's no excuse for any CA not being prepared for this - they knew what was expected because they helped develop the policy.

There are lots of reasons why shorter certs are good; 39 months is itself probably too long. Indeed, if you've been keeping your server up to date and secure, you will find you've been touching it every few months already.

Comment 27 Deleted

rsleevi is referring to the CA/Browser Forum's Baseline Requirements, which CAs participate in drafting, voting on, and accepting. The latest revision of the requirements is here:

https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf

See e.g. page iv: "2015-04-01 9.4.1 CAs SHALL NOT issue certificates with validity periods longer than 39 months."

Chrome is the first browser to enforce the requirement, so you noticed it with Chrome first. But be aware that this is not Chrome being capricious; your CA issued your site's certificate outside the bounds of the Baseline Requirements. You should take up the issue with them. I suggest you do so, politely.

Sign in to add a comment