Comment 1:

Labels changed: added go1.3maybe.

Comment 2:

Can you please attach the certificate, or create a new one demonstrating the bug and
attach that?

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 3 by pavel.odintsov:

Hello!
Please check this certificates. Thank you!

Attachments:

1. gnutls.crt (1196 bytes)
2. gnutls.key.txt (1679 bytes)

Comment 4:

This cert does indeed have a negative RSA modulus:
$ openssl asn1parse -i -dump -in gnutls.crt -strparse 174
    0:d=0  hl=4 l= 265 cons: SEQUENCE
    4:d=1  hl=4 l= 256 prim:  INTEGER           :-17FE30E907088DB4680D2F9C165D24604F1E8E7BB7EAB6AE31F1D6E71E32BD1C56CAAB4AA9DA4EBC376D80EC251DDF428E541264DEBE346DCB500D98E839F0A196EDB76151734E44BC681442B0AF0F85A924EB6FC54FD697BB7588AB841F68361E44EF191D633BCBF86CDA0BC78DAE7C309B5954B8087B074789E761EE7B10A11D9697AB43164004CE67C841BDD5D09A594D23587096D8713A45FEBEF4EBB099576C931D075AEADAE7B8C8B490C0703BEFE6840C4C4AE333C2797EAA9F05ED69685513C701B673E5D671F17F89E40F2B462171D779EA55EA76AF988333639A5BA7A75104003CAAE71F699D1303ABDC60C6C9939DD2C427B3CAFFA327FC5FD675
  264:d=1  hl=2 l=   3 prim:  INTEGER           :010001
$
The GnuTLS ASN.1 encoder should have padded it with a leading NUL byte.
It looks like CentOS 6 uses a modified version of GnuTLS 2.8.5¹ which
is unfortunate since this bug was fixed four years ago² (and included
in the 2.8.6 release).
Cheers,
  Anthony
1. http://vault.centos.org/6.5/os/Source/SPackages/gnutls-2.8.5-10.el6_4.2.src.rpm
2. https://gitorious.org/gnutls/gnutls/commit/3d8da5765133c6ced37bf29b5a07f950b8c26cd7

Comment 5 by pavel.odintsov:

Thank you so much! I will try to send this bug to RH/CentOS.

Comment 6:

Closing as the problem doesn't appear to be in Go in this case.

Status changed to WorkingAsIntended.

I hit the same error trying to do docker pull and isolated root cause back to a known issue with Palo Alto Networks (PAN) SSL intercepting firewall. Here's what we got from PAN support...

According to ASN.1 coding rule modulus values starting with bytes
higher than 0x80 are always treated as negative values, and as such
should be prefixed with 0x00. In your certificate example modulus hex
value starts with 0x88 and that is why it is presented with additional
0x00 when parsed by open-ssl (00:aa:32:1d...). two 0s are added by
open ssl during parsing because of ASN.1 coding rule.

The problem here is that PAN doesn't put 00s in front of the modulus
value of on the fly certificates, which makes them being treated as
irregular on the systems that rely on ASN.1 standard.

This is a known issue to us and we already have a bug # 59030 for it
which has been fixed in PAN-OS 6.0.1 release. So release 6.0.1 and
newer resolve this issue.

Don't know if PAN is using gnutls certtool, but figured I would share for anybody going web proxy thru a corporate firewall, etc...

@swapdisk This issue was closed long ago. If you are having trouble with the current code please open a new issue or ask on golang-nuts. Thanks.

@ianlancetaylor Understood, was just sharing some knowledge regarding other issues that can trigger the same golang error. I also see that Red Hat has just now released updated RHEL6 gnutls-utils package that includes the certtool bug fix at https://rhn.redhat.com/errata/RHSA-2015-1457.html :-)