Issue metadata
Sign in to add a comment
|
X.509 Certificate have a valid SAN but Chrome still returns "Subject Alternative Name missing" error
Reported by
joaopfc...@gmail.com,
Apr 2 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. The attached zip file have a dummy RSA private key and certificate to easily setup a webserver with them with the command openssl s_server -key priv.key -cert www.test.dummy.com.crt -accept 54321 -www (or any other preferred way to setup a webserver) 2. Navigate to https://localhost:54321 3. Open the Dev Console on Chrome. In the Security tab the error "Subject Alternative Name missing" appears, although it exists in the Certificate Extensions What is the expected behavior? Chrome shouldn't have showed the "Subject Alternative Name missing" error since it exists (and it's equal to the subject Common Name) What went wrong? Chrome doesn't recognized the Subject Alternative Name on the X.509 Certificate Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.3 Flash Version: Please find in the attachment: - A private key - The corresponding public key certificate - The Certificate Signing Request issued to our CA - The screenshot of the bug on a Mac OS - The screenshot of the bug on a Windows 10 The screenshots also shows that Windows/Mac OS certificate parser tool and openssl can read the SAN correctly.
,
Apr 2 2018
In the attached screenshots, you appear to be showing a different portion of the Security panel, not the "Subject Alternative Name missing" text that you list in the issue itself? In your repro steps, you omit any steps whereby you've told Chrome to ignore certificate errors and continue anyway?
,
Apr 2 2018
Given that the subjectAltName is set to www.test.dummy.com, but you appear to be accessing it at https://localhost, this seems to be expected - the value 'localhost' is not appearing in the subjectAltName
,
Apr 2 2018
The expectation here is that we'd be getting net::ERR_CERT_COMMON_NAME_INVALID here instead, as the other warning should only be appearing when cert_missing_subject_alt_name comes up from //net.
,
Apr 2 2018
security_info->cert_missing_subject_alt_name =
visible_security_state.certificate &&
!visible_security_state.certificate->GetSubjectAltName(nullptr, nullptr);
,
Apr 2 2018
X509Certificate::GetSubjectAltName is returning |false| at this check:
if (!ParseExtensions(tbs.extensions_tlv, &extensions))
return false;
,
Apr 2 2018
SEQUENCE(3 elem)
OBJECT IDENTIFIER 2.5.29.17 subjectAltName(X.509 extension)
BOOLEAN false
OCTET STRING(1 elem)
SEQUENCE(1 elem)
[2]www.test.dummy.com
It appears that ParseExtension rejects the SubjectAltName extension as it is incorrectly encoded with a default attribute:
if (!out->critical) {
return false; // DER-encoding requires DEFAULT values be omitted.
}
So, ultimately, I believe this is Working-as-Intended. The Developer Tools show the result of certificate validation, and certificate validation deems the SAN in the certificate as malformed.
,
Apr 2 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Apr 2 2018Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug