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...

CC @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

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.

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