Fail to parse key PEM

[Archos]

I'm trying to parse a public/private key pair, but I get this error:

    2013/03/31 23:40:56 crypto/tls: failed to parse key PEM data

Any idea? my system is Ubuntu 12.10 64b

http://play.golang.org/p/4EZCrtQLP8

[Péter Szilágyi]

Hi,

  It would help if you provided the actual file contents too (the cert and key). On my system your code runs ok.

Cheers,

  Peter

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Archos]

The key is the private part of the certificate so it should not go out of the system.
But, I've done some checks:

# openssl verify /etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/ssl/certs/ssl-cert-snakeoil.pem: OK

# openssl verify /etc/ssl/private/ssl-cert-snakeoil.key
unable to load certificate
140652157666976:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:696:Expecting: TRUSTED CERTIFICATE

There is the issue.

My system is Ubuntu 12.10 64 bits with

# openssl version
OpenSSL 1.0.1c 10 May 2012

Any other people with that problem in that system?

[David Anderson]

Looks like your private key is corrupted. Try regenerating the certs (delete them, then dpkg-reconfigure some package... maybe 'openssl' ? Or just use `openssl` to generate a new cert+key).

If regenerating still outputs an invalid private key, I suggest running memtest on your system in case you have bad ram (random file corruption is a common symptom), or looking in dmesg for hard drive errors (symptom of a bad disk).

For reference, I've done SSL key parsing on ubuntu 12.04, 12.10, as well as debian stable. Go's stdlib can parse certs and keys from all those systems just fine.

- Dave

[Archos]

1. I generated a new pair cert+key:

# make-ssl-cert generate-default-snakeoil --force-overwrite

# openssl verify /etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/ssl/certs/ssl-cert-snakeoil.pem: CN = fenix
error 18 at 0 depth lookup:self signed certificate

OK

# openssl verify /etc/ssl/private/ssl-cert-snakeoil.key
unable to load certificate

140173049370272:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:696:Expecting: TRUSTED CERTIFICATE

2. I deleted, and I re-installed ssl-cert:

# rm /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key
# apt-get install --reinstall ssl-cert

But I get the same error than in point 1.

I'm going to running memtest, although my RAM is of Kignston

[David Anderson]

I recently RMA'd Kingston ram for many deterministic memory errors (detected by memtest). I've learned that you should never trust your ram if it's not ECC (and even then, run memtest on it and check for a high level of corrected errors).

In the end, I swapped my motherboard for one that supports ECC, and use only ECC ram in machines that I care about (file servers and such). Non-ECC ram is fine for gaming and browsing the internet, but for any serious use, I no longer trust it.

- Dave

[Archos]

My RAM memory is ok.It tools about 20 min. to checking a module of 4GB DDR3.

But looking at dmesg, I founf several errors like:

[    5.243863] mtrr: type mismatch for e0000000,400000 old: write-back new: write-combining

Could it be the problem?

By the way, I didn't find any error related to hard disk: `dmesg |grep sd |less`

[David Anderson]

On Mon, Apr 1, 2013 at 1:02 AM, Archos <raul...@sent.com> wrote:

My RAM memory is ok.It tools about 20 min. to checking a module of 4GB DDR3.

That sounds good, but for reference, my bad ram chip took 1.5hrs of memtest to reveal an error. That error was deterministic, every time memtest tested that ram chip, there was an error.

 

But looking at dmesg, I founf several errors like:

[    5.243863] mtrr: type mismatch for e0000000,400000 old: write-back new: write-combining

Could it be the problem?

I don't know, but a bit of searching on Google says that you could try upgrading your kernel, because MTRR errors are common on older kernels (missing definitions for modern cpus, or problems with old video drivers).

However, the problems that people on Google have aren't related to problems generating SSL certs.

How long ago did you install your Ubuntu system? I just tried a 12.04 system, and I had no problem with SSL keys. So, if you don't find a ram problem, my next theory is either a bad hard drive, or a corrupted Ubuntu installation. Generating invalid SSL keys is a very strange problem :/.

- Dave

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

[Archos]

My kernel is not old, I have 3.5.0-26-generic. So the MTRR errors could be due to the bios.

And to discard that it's an error related to my system installed, I installed Ubuntu server 12.04 64 bits under VirtualBox, and after of install `ssl-cer`, I verified the key file getting with the same failure.

[Archos]

This is one of the last things to checking. Does anybody could test this private key in your system?

http://pastebin.com/m0s3eHY9

+ openssl verify cert-test.key

[Archos]

Solved! Thanks to the help of Lucio De Re.

To start, `openssl verify` is to ckecking only the public key, not for the private key. Into a system like NetBSD, it is said clearly.

+ Check public key of certificate:

    $ openssl verify /etc/ssl/certs/ssl-cert-snakeoil.pem

+ Check private key of certificate:

    # openssl rsa -noout -text -in /etc/ssl/private/ssl-cert-snakeoil.key

I was using version devel +2a4a89b1f36b. I checked if there were any problem in the library:

    $ cd $GOROOT/src/pkg/crypto/tls
    $ go test -i
    $ go test

The tests were ok. Anyway, I updated to tip version and the problem has been solved.

[Archos]

Thanks for to try help and for the information.
Although the issue has been solved at installing tip version, the first time I'll buy a motherboard with ECC support if it is not too expensive.