Treat failure to parse certificates as SSL protocol errors.

Right now, failure to parse certificates map to ERR_SSL_PROTOCOL_ERROR
(or ERR_FAILED in NSS because our error-mapping logic isn't very good
for either case), however since we use two certificate libraries
together, it's possible for BoringSSL to accept a certificate while
the platform doesn't. (Especially so because BoringSSL is still using
OpenSSL's legacy X.509 stack which is very shoddy. Also Windows will
refuse to parse things like certificates which expire on 0001-01-01.)

Today, this results in ERR_CERT_INVALID (IsCertificateError gives true)
with a NULL X509Certificate, crashing everywhere. Instead, these errors
should be treated the same as if BoringSSL internally rejected the
certificate. Map them to a new error code (for ease of debugging),
ERR_SSL_SERVER_CERT_BAD_FORMAT. IsCertificateError will return false
for this error.

We should now actually maintain the invariant that IsCertificateError
implies there is a certificate available.

The user-visible error page just inherits ERR_SSL_PROTOCOL_ERROR's
strings, as there is no meaningful difference between "BoringSSL
rejected the cert" and "BoringSSL rejected the cert but Windows didn't".
Likewise, this error is unrecoverable, matching ERR_SSL_PROTOCOL_ERROR.

This removes support for using SSLClientSocket in an environment
where X509Certificates cannot be created. With remoting no longer using
the internal plugin, this is no longer necessary.

BUG=91341

Review URL: https://codereview.chromium.org/1286793002

Cr-Commit-Position: refs/heads/master@{#343720}

0 files changed, 0 insertions, 0 deletions