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:
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.
> 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.
oh, okay. that helps to understand it better. I'll work on it soon.
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?
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