Bug 583047

Summary: Certmaster generate CA certificates with old x509 version, lacking basic constraints & using insecure signature algorithm
Product: [Fedora] Fedora Reporter: Daniel BerrangĂ© <berrange>
Component: certmasterAssignee: Seth Vidal <skvidal>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: alikins, brett.lentz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-22 21:10:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Daniel Berrangé 2010-04-16 14:28:53 UTC
Description of problem:
Certmaster is generating x509 Version 1 certificates, which means it is impossible to include basic constraints. It is also using the known insecure 'md5' signature algorithm to sign them.

With any of these 3 problems, let alone all of them, the CA certificate will not be trusted by many SSL clients. This is making it impossible to validate connections using certificates generated by certmaster, with any gnutls based app.

Compare a certmaster CA cert

# certtool --infile cacert.pem -i
X.509 Certificate Information:
        Version: 1
        Serial Number (hex): 00
        Issuer: C=UN,ST=FC,L=Certmaster-town,O=certmaster,OU=slave-key,CN=lettuce.camlab.fab.redhat.com-CA-KEY,EMAIL=root
        Validity:
                Not Before: Fri Apr 16 12:50:30 UTC 2010
                Not After: Mon Apr 13 12:50:30 UTC 2020
        Subject: C=UN,ST=FC,L=Certmaster-town,O=certmaster,OU=slave-key,CN=XXXXX.com-CA-KEY,EMAIL=root
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        08:1c:38:6e:7a:8c:52:ea:a8:3b:54:45:be:d7:47:01

                Exponent (bits 24):
                        01:00:01
        Signature Algorithm: RSA-MD5
warning: signed using a broken signature algorithm that can be forged.



With a CA certificate generated using stanard GNUTLS config


X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 00
        Issuer: CN=Red Hat
        Validity:
                Not Before: Mon Sep 17 17:35:47 UTC 2007
                Not After: Tue Sep 16 17:35:47 UTC 2008
        Subject: CN=Red Hat
        Subject Public Key Algorithm: RSA
                Modulus (bits 1024):
                        e6:9d:0b:41:27:9c:24:85:34:4b:b9:68:40:c5:e1:7b
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Key Usage (critical):
                        Certificate signing.
                Subject Key Identifier (not critical):
                        44f1a33c5aea83e8d0cd2ae7051097d63637d492
        Signature Algorithm: RSA-SHA


Notice the extensions indicating this key is for a CA, is version 3 and using RSA-SHA instead of MD5


Version-Release number of selected component (if applicable):
certmaster-0.25-2.fc12.noarch

How reproducible:
Always

Steps to Reproduce:
1. Start certmaster service
2. Run certtool --infile /etc/pki/certmaster/ca/ca.cert -i
3.
  
Actual results:
No basic constraints shown. Insecure signature algorithm

Expected results:
Basic constraints for CA + secure signature algorithm

Additional info:

Comment 1 seth vidal 2010-04-16 15:09:39 UTC
two items:

1. I'll work on the constraints for the cert generation
2. func upstream can use non-certmaster certs for interacting with minions, so we're no longer bound only to certmaster certs.

Comment 2 Daniel Berrangé 2010-04-16 18:53:51 UTC
> 2. func upstream can use non-certmaster certs for interacting with minions, so
> we're no longer bound only to certmaster certs.  

I was actually not trying func in this case. I was looking to make use of certmaster as an easy way to deploy certificates for libvirt and QEMU's VNC server (which supports TLS). It looks like certmaster will do the job quite well once the CA certs are generated in a way that gnutls trusts them.

Comment 3 seth vidal 2010-04-16 19:07:30 UTC
oh, okay. that helps to understand it better.

I'll work on it soon.

Comment 4 seth vidal 2010-04-22 18:30:51 UTC
A couple of questions - according to 

openssl list-message-digest-commands

the only supported digests are:
md2
md4
md5
rmd160
sha
sha1


so my question is - is 'sha' good enough?

Comment 5 seth vidal 2010-04-22 21:10:19 UTC
I've implemented the basic constraints, a sha signature algorithm and key version 3. So - yay - however, I cannot add subject key identifiers or authority key identifiers without a newer version of pyopenssl than is reasonably available on a variety of platforms.

http://git.fedorahosted.org/git/?p=certmaster.git;a=commitdiff;h=8d70412c35fb1f0538577ec578e5f0568421dcf0