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

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?

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.

 Issue 810671  has been merged into this issue.