On the last day of the year my email stopped coming in. You may have read about my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email. Well, on the last day of the year my ROOT CERTIFICATE, which I use for Kerry Linux, had expired after five years. Time flies by.
As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.
After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.
Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.
As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.
After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.
Re-Animation of the old ROOT KEY
After a while I began to wonder if it was possible to reanimate the old key and out of curiosity tried to explore the way to do it in more detail. I googled and found this nice posting from Arsen Hayrapetyan which led me to success. My former attempts to recreate the old certificate always led me to the following error message when I tried to verify a user's certificate::
openssl verify -verbose -CAfile KLCC-2010.pem support@kerrylinux.ie.cert
support@kerrylinux.ie.cert:
/C=IE/ST=Ireland/L=Kerry/O=Kerry Linux/CN=support@kerrylinux.ie/emailAddress=support@kerrylinux.ie
error 20 at 0 depth lookup:unable to get local issuer certificate
/C=IE/ST=Ireland/L=Kerry/O=Kerry Linux/CN=support@kerrylinux.ie/emailAddress=support@kerrylinux.ie
error 20 at 0 depth lookup:unable to get local issuer certificate
Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.
So I followed Arsen's hints and created a testbed for an experiment, where I set the serial number back to 00 and emptied the file "index.txt" so that my new certificate could inherit the properties of the old one including its serial number. Then I created a new certificate request based on the old root certificate "cacert.cert" and used this new request to sign it with the old key.
openssl x509 -x509toreq -in cacert.cert -signkey private/cakey.pem \
-out certreq.csr
openssl ca -config KLCC.cnf -in certreq.csr -out cacert_renewed.pem \
-keyfile private/cakey.pem -cert cacert.cert -extensions v3_ca
-out certreq.csr
openssl ca -config KLCC.cnf -in certreq.csr -out cacert_renewed.pem \
-keyfile private/cakey.pem -cert cacert.cert -extensions v3_ca
The result was a new root certificate "cacert_renewed.pem" that verified my old user certs
perfectly.
openssl verify -verbose -CAfile cacert_renewed.pem \
support@kerrylinux.ie.cert
support@kerrylinux.ie.cert: OK
support@kerrylinux.ie.cert
support@kerrylinux.ie.cert: OK
It's good to have an alternative, isn't it?


Leave a comment