Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 870466 - Cannot create a certificate with certtool
Cannot create a certificate with certtool
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnutls (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-26 10:51 EDT by Michael Cronenworth
Modified: 2014-07-31 11:23 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-31 11:23:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
key.pem (2.02 KB, application/x-x509-ca-cert)
2013-03-08 09:59 EST, Michael Cronenworth
no flags Details
example CA certs (2.73 KB, application/x-xz)
2013-03-08 11:54 EST, Michael Cronenworth
no flags Details

  None (edit)
Description Michael Cronenworth 2012-10-26 10:51:27 EDT
Description of problem: I tried to follow the manpage example for certtool to generate a certificate (x509 public/private keys). I can create the private key, but attempts to generate the public key fail.

$ certtool --generate-privkey --outfile key.pem
Generating a 2432 bit RSA private key...
$ ll
total 4
-rw-------. 1 mcronenworth users 1968 Oct 26 09:35 key.pem
$ certtool --generate-certificate --load-privkey key.pem --outfile cert.pem --load-ca-certificate ../CA/ca.pem --load-ca-privkey ../CA/ca-key.pem 
Generating a signed certificate...
certtool: importing --load-privkey: key.pem: ASN1 parser: Error in DER parsing.


Version-Release number of selected component (if applicable):
$ rpm -q gnutls
gnutls-2.12.17-1.fc17.x86_64

How reproducible: Always

Actual results:
No certificate file is generated.

Expected results:
Certificate file.
Comment 1 Michael Cronenworth 2013-03-06 11:42:32 EST
This is still a bug with GnuTLS 2.12.23, but with a slightly different message.

Generating a signed certificate...
certtool: importing --load-privkey: key.pem: ASN1 parser: Error in TAG.
Comment 2 Tomas Mraz 2013-03-08 09:52:59 EST
Unfortunately I cannot reproduce it. Is this 100% reproducible for you? Can you please attach the key.pem file that gives you the error?
Comment 3 Michael Cronenworth 2013-03-08 09:59:16 EST
Created attachment 707084 [details]
key.pem

Yes, it is 100% reproducible for me.

$ rpm -q gnutls
gnutls-2.12.23-1.fc18.x86_64
$ certtool --generate-privkey --outfile key.pem
Generating a 2560 bit RSA private key...

Attached.
Comment 4 Tomas Mraz 2013-03-08 10:30:13 EST
Unfortunately it is still not reproducible for me even with the attached key file. So that narrows it to the key file loading and it is probably dependent on the hardware of the machine. (I tested it in a KVM virtual machine.)
Comment 5 Michael Cronenworth 2013-03-08 10:41:50 EST
(In reply to comment #4)
> Unfortunately it is still not reproducible for me even with the attached key
> file. So that narrows it to the key file loading and it is probably
> dependent on the hardware of the machine. (I tested it in a KVM virtual
> machine.)

OK, it seems something is misconfigured on the machine I am trying to use. I loaded gnutls-utils on a separate, physical machine and I was able to use certtool successfully. Both machines are 64-bit.

Are there any config files I may have inadvertently added to my system I can look for? Perhaps it is dlopen()ing a library I have that doesn't live on the systems that work?

$ rpm -qV gnutls gnutls-utils
Comes back with no modified files.
Comment 6 Tomas Mraz 2013-03-08 11:26:12 EST
The parsing is done by libtasn1. Perhaps you have some weird/miscompiled version on the system?
Comment 7 Michael Cronenworth 2013-03-08 11:54:07 EST
Created attachment 707124 [details]
example CA certs

OK, I think I have narrowed down the problem as the certtool error message is misleading. The CA cert key I am using is the problem. I have re-created a test CA that reproduces the issue.

The CA was generated with openssl and when I generated it on a working system I did it with different commands than the CA that was on the non-working system.

Working CA certs:
openssl genrsa -out example_ca_cert.key 2048
openssl req -config ssl.cnf -new -x509 -days 3650 -key example_ca_cert.key 
-out example_ca_cert.crt -extensions v3_ca

Non-working CA certs:
openssl req -new -x509 -extensions v3_ca -keyout exampleca-key.pem -out exampleca.pem -days 7500 -config ./openssl.cnf

I have attached certs generated with the non-working command.

Should I reassign this to libtasn1? I don't think GnuTLS is to blame, but the certtool error message could be more clear.
Comment 8 Fedora End Of Life 2013-12-21 04:12:30 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Michael Cronenworth 2014-01-15 17:08:21 EST
This appears to be fixed in Fedora 20.

Note You need to log in before you can comment on or make changes to this bug.