ASN1 PrintableStrings must not contain @, https://en.wikipedia.org/wiki/PrintableString.

Can you please explain more about your problem, preferably showing code or a failing test case.

The client certificate I was given to use has a @ in the PRINTABLESTRING :commonName

e.g.

(output from openssl asn1parse -in client_cert.pem)

  367:d=3  hl=2 l=  32 cons: SET               
  369:d=4  hl=2 l=  30 cons: SEQUENCE          
  371:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  376:d=5  hl=2 l=  23 prim: PRINTABLESTRING   :BLAH BLAH @US SOFT CA v3

^^ Not sure how in the world that got in there.

It's interesting how other libs and langs handle this ugly issue gracefully. I've tried: curl, objective-c, nodejs, php, and openssl s_client and they all seem to be parsing the the cert without strictly validating the strings. I can easily change the encoding type in the binary blob from 0x13 to 0x0c but that will change the cert signature and decryption of data will fail at a later point. Any ideas?

I think the go behaviour is correct, and arguments that other languages don't validate don't really feel appropriate where security is involved.

/cc @agl

I totally agree.

Can you get a valid certificate?

In general we don't want to cater to all possible ways a certificate might be broken. If this kind of thing is endemic in the wild then we might make an exception, but if it's just a one-time mistake, it's not appropriate for the Go standard library to sanction it.

It sounds like you know a workaround (recompile your version of Go).

Unless there is evidence this kind of problem affects many many users, I think we'll stick with spec compatibility.

Unfortunately, I can't get a valid certificate 😒 But anyways, deff stick with spec compatibility... I don't expect an exception for a single anomaly. Thanks for the support.