Treat failure to parse certificates as SSL protocol errors.

net/data/ssl/certificates/README

Index: net/data/ssl/certificates/README
diff --git a/net/data/ssl/certificates/README b/net/data/ssl/certificates/README
index 3f76a2a101cc12129e8f60b7ac30e323fd9f9009..fd59cce67ace5e8b338595bdd956b4b4350b9613 100644
--- a/net/data/ssl/certificates/README
+++ b/net/data/ssl/certificates/README
@@ -129,6 +129,9 @@ unit tests.
 - quic_root.crt
      These certificates are used by the ProofVerifier's unit tests of QUIC.
 
+- bad_validity.pem : A certificate with bogus notBefore and notAfter fields.
+     Windows refuses to parse this certificate.

[Ryan Sleevi, 2015/08/12 22:03:19]

It'd be preferable to not manually generate this. Can you add it to one of the
test scripts?

[davidben, 2015/08/12 22:14:05]

This was generated from the Go program attached in the bug. There's no reason to
ever regenerate it since it will never expire. If you give me an OpenSSL
command-line to generate such a certificate, I'll include it, but I as a general
rule try to avoid that tool. :-P Generating certificates with anything but Go is
just a pain.

[Ryan Sleevi, 2015/08/13 22:54:57]

Eh, that's what we said about the certs until we switched SHA-1 to SHA-256 ;)
That may be, but it's also the consistent way that multiple developers can
collaborate (especially developers who hate Go :P). 

Load up net/data/ssl/scripts/generate-test-certs.sh . You can see explicit date
assignment at
https://code.google.com/p/chromium/codesearch#chromium/src/net/data/ssl/scrip...
as an example.

You can see explicit name assignment at
https://code.google.com/p/chromium/codesearch#chromium/src/net/data/ssl/scrip...

It uses ASN1_TIME_set_string, which should handle dates even outside the
representation of a time_t

[davidben, 2015/08/14 22:42:36]

Done. Yeah, I really don't like using openssl x509. It's obnoxious. :-) Used Go
to do CVE-2015-1793 as well.

+
 ===== From net/data/ssl/scripts/generate-test-certs.sh
 - expired_cert.pem
 - ok_cert.pem