Issue appears to be a duplicate of #15842 . The patch appears to have been ready during the 1.11 time frame but hasn't made the cut since. I replied to the associated CL to see if someone can make a call.
Yeah, the patch for #15842 just makes it so encoding/asn1 will parse in a date with fractional seconds rather than dropping the fraction part. Then when the package formats the parsed date as a string to compare with the original it works for that case.
The problem here is that when encoding/asn1 formats the parsed date and compares it to the original string, that original +0000 offset gets formatted as Z, so it doesn't match the original string. That happens right here.
My patch for #15842 has the purpose of enabling the parsing of fractional digits in GeneralizedTime (From my understanding of X.690, p. 20, fractional digits are allowed in GeneralizedTime, but not in UTCTime).
This issue (33192), though, is related to UTCTime, not GeneralizedTime. (So the patch for #15842 won't fix this issue already for the reason that a different function is called for parsing).
If you list the ASN.1 data from the certificate above using
openssl x509 -in cert.pem -outform der | openssl asn1parse -inform der
I wonder if the +0000 suffix is correct, since X.609 states that UTCTimes in DER encoding must end in Z. See https://forums.openvpn.net/viewtopic.php?t=21873#p62295 for a related discussion; RFC5820 (and RFC2459), which is referenced there, also requires UTCTime with a Z suffix.
One approach would be to make asn1.go:parseUTCTime conservatively accept a +0000 suffix. The if condition in asn1.go:345 could be extended by a test like