crypto/x509: ParseCertificate error: PrintableString contains invalid character

[Bubsavvage]

What version of Go are you using (go version)?

$ go version
1.13.4

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
Linux Centos 7

What did you do?

Attempted to use "x509.ParseCertificate" on our issuers certificate, but fails due to a "_" character which fails the ASN.1 Spec for PrintableString.

Due to company violations this is not possible. The way to reproduce this is to generate a certificate with a ASN.1 PrintableString field that contains an "_" character and attempt to parse it.

What did you expect to see?

The x509 certificate to be parsed succesfully

What did you see instead?

crypto/x509: ParseCertificate error: PrintableString contains invalid character

[Bubsavvage]

Would it be at all possible to add in the underscore character for this as well? An exception was made for ampersand and @ in other issues #21339. Our team has come across a ASN.1 PrintableString field that contains a underscore in it. Its not possible for us to regenerate the certificate at the moment because too many applications rely on the existing one. Or you could give us a "strict" vs "non-strict" option when parsing certificates. Currently we are using go1.13.4 and had to manually change the ASN.1 golang parser, which is not sustainable...

[ianlancetaylor]

CC @FiloSottile

[FiloSottile]

The Go crypto libraries are intentionally strict when the standards allow it, and this is clearly a standard violation. The two exceptions that we support are one for an extremely common mistake (*), and the other for a mistake that made its way in a trusted root. Using _ does not seem nearly as common since this is the first issue opened about it. Note that the issue you reference was actually rejected (#21339) for the same reason: the certificate is invalid.

There are forks of crypto/x509 with different goals, like https://github.com/zmap/zcrypto/tree/master/x509 which prioritizes compatibility instead of providing security for production systems

[Bubsavvage]

That seems fair. Luckily i think these certs expire soon, so maybe we can push for a correction. If not we will have to continuously be aware of this issue every time we want to update to a newer version of golang. My question would now be what is the justification for the ASN.1 spec not including these characters for PrintableString? The term PrintableString i would say sounds like it should be any valid UTF-8 character, but of course this is just an opinion.

[FiloSottile]

ASN.1 is an extremely old standard, and has plenty of quirks. There is a specific type for UTF-8 strings.