New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 410574



Sign in to add a comment

OSX 10.13 rejects certificates with overlong serial number

Reported by pepis...@cisco.com, Nov 18 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
1.Upgrade MAC to high sierra 
 Trust proxy's SSL intermediate cert and the CA cert in Keychain; selecting always trust
2. Have proxy decrypt SSL traffic
3. receive the error 'NET::ERR_CERT_INVALID

What is the expected behavior?
Chrome should inherit certificate trust settings in keyChain, but it is not after upgrading to High Sierra 

What went wrong?
 receive the error 'NET::ERR_CERT_INVALID
-unable to access HTTPS pages 

Did this work before? Yes when MAC was running El Captain chrome never experienced this issue 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: 10.13
Flash Version:
 
chrome-net-export-log (1).json
20.8 MB Download
Components: Internals>Network>Certificate
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
ERR_CERT_INVALID typically indicates that there's a problem with the certificate itself, not with the trust of the certificate chain. 

This may be a duplicate of Issue 763631.
Taking a look at a certificate in the capture, it has a 37 byte serial number:
serial number: 00b831f8a20e5bf2c6ea4096a8ec6a309931034102b3164157828e0756955d42fd7ea165c6

The specification requires that certificates have serial numbers of 20 octets or less. That violation isn't likely to be causing the problem reported (because crrev.com/472040 relaxed our serial number validation), but it could prove problematic for such certificates in the future.

Other issues noted by zlint include:	
ERROR	CAs must include keyIdentifer field of AKI in all non-self-issued certificates
ERROR	CAs must support key identifiers and include them in all certificates
ERROR	Certificates must not have a serial number longer than 20 octets
ERROR	Subscriber Certificate: authorityInformationAccess MUST contain the HTTP URL of the Issuing CA's OSCP responder.
ERROR	Subscriber Certificate: certificatePolicies MUST be present and SHOULD NOT be marked critical.
ERROR	Subscriber certificates must contain at least one policy identifier that indicates adherence to CAB standards
ERROR	Subscriber Certiifcate: authorityInformationAccess MUST be present, with the exception of stapling.
WARNING	Subscriber certificates authorityInformationAccess extension should contain the HTTP URL of the issuing CA’s certificate
Subscriber Certificate: commonName is deprecated.
Errors for the CA in that chain:

ERROR	basicConstraints MUST appear as a critical extension
ERROR	CAs MUST include a Subject Key Identifier in all CA certificates
ERROR	CAs must include keyIdentifer field of AKI in all non-self-issued certificates
ERROR	CAs must support key identifiers and include them in all certificates
ERROR	Root and Subordinate CA certificate keyUsage extension MUST be marked as critical
ERROR	Subordinate CA Certificate: authorityInformationAccess MUST be present, with the exception of stapling.
ERROR	Subordinate CA certificates authorityInformationAccess extension must contain the HTTP URL of the issuing CA’s OCSP responder
ERROR	Subordinate CA certificates must have a certificatePolicies extension
WARNING	Subordinate CA Certificate: authorityInformationAccess SHOULD also contain the HTTP URL of the Issuing CA's certificate.
WARNING	The keyUsage extension SHOULD be critical

Comment 4 Deleted

Comment 5 by mattm@chromium.org, Nov 20 2017

Did some tests with the chain. On High Sierra, the OS fails on parsing the leaf cert in SecCertificateCreateFromData. It returns status -25257, which seems to be "Unknown format in import." I hacked up a version of the cert with a shorter serial number, and then SecCertificateCreateFromData succeeded.

So I guess Apple has tightened up their parsing in 10.13. You'll need to generate your certs with a spec-compliant serial (or bug Apple about this), there's nothing we can do about this from the chrome side.
Re #5, should this be WONTFIX?

Comment 7 by mattm@chromium.org, Feb 9 2018

Blockedon: 410574
Status: Available (was: Unconfirmed)
Summary: OSX 10.13 rejects certificates with overlong serial number (was: Chrome not trusting Intermediate/Root Certs in Keychain)
That would be reasonable. Though, in theory switching to the built-in verifier eventually would allow us to avoid it, so could mark it blocked on that instead.
Cc: ellyjo...@chromium.org elawrence@chromium.org
 Issue 810671  has been merged into this issue.

Sign in to add a comment