crypto/x509: unable to parse certificate with a negative serial number

[gopherbot]

by ayazdi:

go version: go1.2.1 linux/amd64

Trying to parse an X509 certificate with a negative serial number results in the
following error:

x509: negative serial number

(see http://play.golang.org/p/zpXKadV5mo for an example)

This means an SSL/TLS connection cannot be established to a server that uses this kind
of certificate.

Although RFC 5280 [1] section 4.1.2.2 specifies that serial numbers MUST be positive, it
also says that implementations SHOULD handle non-positive serial numbers gracefully. 

Note that RFC 2459 (obsoleted by RFC 3280, which was in turn obsoleted by 5280) did not
require the SN to be positive.

[1] http://www.ietf.org/rfc/rfc5280.txt

[gopherbot]

Comment 1 by mcmoranbjr:

Aside from not following the RFC, the behavior is inconsistent within std library
consumers of tls which make use of tls.Client connections. 
Check out the following for more detail:
https://groups.google.com/forum/#!topic/golang-nuts/lEfVw4ySj5g

[griesemer]

Comment 2:

Labels changed: added release-go1.4maybe, repo-main.

[rsc]

Comment 3:

->agl for triage

Status changed to Accepted.

[agl]

Comment 4:

If you find a CA that is issuing certificates like this, please let me know and I'll
complain to them.

Owner changed to @agl.

[rsc]

Comment 5:

Sounds like a 'WorkingAsIntended' to me.

Status changed to WorkingAsIntended.

[bytheway]

Comment 6:

I am a new user to Go and just experienced this today.  We use the WebLogic java
application server and by default, it generates certificates for admin ports that use
negative serial numbers.
Yes, we probably should get "real" certs, but all the servers are behind a firewall, for
internal use only, so we've never bothered.
What about eliminating the negative serial number check only when InsecureSkipVerify ==
true?

[gopherbot]

Comment 7 by lgtdrivesme:

The negative serial was coming from HP iLO3 devices running firmware 1.5. The device
certificate was reissued during the firmware update and because, HP, the new certificate
had a negative serial number. Subsequent firmware updates fixed the issue. I would
support the notion this is a vendor problem and the suggestion the vendor be set ablaze
or clubbed to death.

[gopherbot]

Comment 8 by mcmoranbjr:

The negative serial was coming from HP iLO3 devices running firmware 1.5. The device
certificate was reissued during the firmware update and because, HP, the new certificate
had a negative serial number. Subsequent firmware updates fixed the issue. I would
support the notion this is a vendor problem and the suggestion the vendor be set ablaze
or clubbed to death.

[bytheway]

Comment 9:

I agree that this is a bad practice by vendors, but not having some kind of override
makes using go

[bytheway]

Comment 10:

I agree that this is a bad vendor practice, and in a perfect world we could just make
every vendor do the right thing.
But, by making this a hard requirement, with no way to turn it off, it makes it hard for
us to replace some of our current (ruby) scripts with equivalent/better go versions.

[gopherbot]

Comment 11 by takekazu.omi@kyrt.in:

> I am a new user to Go and just experienced this today
me too!
I used Windows 8.1 makecert for create self signed certificates.
$ makecert -r -pe -n "CN=Hoge 20141026001" -a sha1 -ss My -len 2048 -sy 24 -b 10/26/2014
-e 01/01/2024 -sv hoge20141026001.pvk hoge20141026001.cer
I got negative serial number 2 times out of 4.
$ openssl x509 -in .\takekazu_omi_azure_20141026005.cer -inform der -serial
serial=-05B57C18EAC6AB57BC5135E6105B880B

[gopherbot]

Comment 12 by mendsley:

Just hit this today. We were issued a certificate with a negative serial from 
Microsoft's Xbox Cloud Security CA.