gabyhelp
commented
2 weeks ago Related Issues and Documentation
- crypto/x509: unable to parse certificate parsable by Java #33259
- crypto/x509: invalid certificate policies #65990 (closed)
- crypto/x509: failed to parse X509 certificate #52742 (closed)
- crypto/x509: unable to parse certificate with rsassa-pss algorithm #48314
- crypto/x509: error parsing large ASN.1 identifiers #49678 (closed)
- crypto/x509: cannot parse certificate IP \& net/http cannot ignore this certificate error #65829 (closed)
- x/crypto: x509: invalid certificate policies #53773 (closed)
- crypto/x509: Verification of ECDSA signed x509 cert, sanitized to LowS certs fails verification with go 1.19 #54549
- crypto/tls: LoadX509KeyPair fails to parse some keys, yet they are accepted by OpenSSL #21807 (closed)
- crypto/x509: ParsePKCS1PublicKey expects invalid key format #29141 (closed)
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
martoche
mateusz834
dr2chase
zpavlinovic
Go version
go version go1.23.2 darwin/arm64
Output of
go envin your module/workspace:What did you do?
I received from my bank a x509 certificate in the PEM format to be used to connect to one of their services.
I passed the certificate to the
openssl x509command-line program to print a textual representation of the certificate: it worked.Then I tried to parse the certificate in go using
x509.ParseCertificateas shown in the following example program: https://go.dev/play/p/jtIyu3C6fL1What did you see happen?
The go example program fails with this error:
What did you expect to see?
Because the
opensslcommand succeeded, I expected the go program to work as well, and to print the parsed certificate.Here is the output of the
opensslcommand, it doesn't have any warning or error.I've tracked down the problem by comparing the execution of my go program in the delve debugger with the execution of the openssl in the lldb debugger.
The error in go happens in the asn1 parser, specifically in the
ReadASN1BitStringfunction, at this very specific line: https://cs.opensource.google/go/x/crypto/+/71ed71b4faf97caafd1863fed003e9ac311f10ee:cryptobyte/asn1.go;l=561The result of the expression
bytes[len(bytes)-1]&(1<<paddingBits-1)is not equal to0, so theReadASN1BitStringfunction returnsfalse(ie: an error occured).(In my specific example,
paddingBitsis equal to5and bytes is equal to[136])My understanding is that the go authors decided that if the padded part of the bit string is not equal to zero, then the function should fail.
In openssl, the equivalent line is this one: https://github.com/openssl/openssl/blob/e54526413d5ef7c665e25f552f2f01d4352bd33d/crypto/asn1/a_bitstr.c#L121
We see that the openssl library doesn't behave like the go library: instead of failing if the padded part of the bit string is not equal to zero, it sets the value of the padded part to zero.
(In my specific example,
136 & (0xff << 5) == 128).The rust authors seem to have made the same choice as openssl. See the comment that says
The "unused bits" are set to 0.in this file: https://docs.rs/der/latest/src/der/asn1/bit_string.rs.html#56If my analysis is correct, I suggest to relax the ASN1 bit string parser by allowing non-zero padding and then setting it to zero like openssl and rust does.