wbond / badtls.io Goto Github PK

See https://travis-ci.org/wbond/asn1crypto/jobs/484426316 and e.g. https://required-auth.badtls.io:10003/
Cert expired 2019-01-01.

wbond/asn1crypto@e1fa6cd fixed how asn1crypto.x509.Name.build() encodes distinguished names. However badtls.io might still serve certificates created with an older version of asn1crypto.

A bit of background: ouspg/trytls#231 stumbled onto how go1.7 fails some badtls.io tests with rather surprising error messages. @joneskoo created issue golang/go#16834, which in turn spawned issue golang/go#16836, which in turn hints that the trigger might have been the way x509.Name.build() used to work.

Most of the badtls.io test certificates contain only a common name and no subjectAltNames. Support for such certificates is deprecated, in the process of being deprecated or not implemented to begin with in some libraries and applications. For reference:

• urllib3: urllib3/urllib3#497
• Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=308330
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1088998
• webpki: briansmith/webpki#11

It might be a good idea to add subjectAltNames to badtls.io certificates. That would allow testing a wider variety of subjects, and maybe even avoid false passes (such as not rejecting expired.badtls.io:11006 because of expiration, but because of missing subjectAltNames).

Can you please add a license (e.g. MIT) so that it's easier to reuse this? Thanks!

There exists a TLS Security Policy a TLS certificate requestor can opt into*, to tell the client something like “if you don't see a recent OCSP attachment on this handshake, assume you're being MitM'd by an attacker who doesn't want you to see the CRLs.”

I'm very curious whether my browser implements this “SHOULD”, but I haven't been able to find a test site for it: https://datatracker.ietf.org/doc/html/rfc7633

A server offering an end-entity certificate with a TLS feature extension MUST satisfy a client request for the specified feature unless this would be redundant as described below. Clients MAY refuse to accept the connection if the server does not accept a request for a specified feature.

…

In the case that a client determines that the server configuration is inconsistent with a policy specifying support for the TLS status_request extension it SHOULD reject the TLS configuration.

*Let's Encrypt has apparently supported this since mid-2016, with --must-staple on its Certbot client.