own Certificate Authority: Renewal of CA cert

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

own Certificate Authority: Renewal of CA cert

Andreas Grimmel
Hello list,

let me say first that I'm not too deep into the secrets of openssl, I just like it as being a stable, great-working software for all concerns of dealing with encryption and especially x.509 certificates for my VPN connections, webservers, and so on.

I got one big problem for now: My self-signed CA cert will expire in about one month. I installed it 4 years ago and never minded about, but now I have to renew it.
The Creation of a whole new CA and client certificates isn't possible for me because of the large number of clients using my certs (VPN Roadwarriors, Webservers, Mailservers, and so on).
Since I didn't find very much useful information on the net concerning the renewal of certificates (might be I did the wrong searches?), I want to ask you some points:

- First of all, is there any HowTo that deals not only with creaton, but also with the renewal of self-signed CA certs in detail?

More detailed, and for addressing my actual problem right now, I'd need to know

- Is it possible to renew a CA cert that way, that those user certs which I signed with the old CA cert shortly (means less than one year) ago, still remain valid?
   - if yes, how would I manage this using the good old openssl commands ?

- I assume I have to replace the old with the new CA cert on every client machine where it is installed, as long as I don't set up a web based (e.g. url-fetching) mechanism - correct?

Your help is GREATLY appreciated - and thanks a lot in advance.

Andreas Grimmel
System Administrator
- down to his knees - ;-)


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: own Certificate Authority: Renewal of CA cert

Patrick Patterson-3
Hi Andreas:

Andreas Grimmel wrote:
> Hello list,
>
<snip>
> I got one big problem for now: My self-signed CA cert will expire in
> about one month. I installed it 4 years ago and never minded about, but
> now I have to renew it.

> The Creation of a whole new CA and client certificates isn't possible
> for me because of the large number of clients using my certs (VPN
> Roadwarriors, Webservers, Mailservers, and so on).
> Since I didn't find very much useful information on the net concerning
> the renewal of certificates (might be I did the wrong searches?), I want
> to ask you some points:
>
> - First of all, is there any HowTo that deals not only with creaton, but
> also with the renewal of self-signed CA certs in detail?
>

That depends on what you need to do by policy for renewal. There is no
such thing as "technical renewal" - there is only policy based. Since
this sounds like an ad-hoc CA without a formal Certificate Policy, you
have some choices:

1: Assuming that you've got a sane key length (RSA 1024 or greater),
just create a new, self signed certificate with a new validity period
and the exact same name as your old one. That way, you'll be able to
just keep issuing CRL's with the same keys, and nothing will break.
You'll have to distribute out the new certificate to your relying
parties, but you'll have to do that no matter what you do.

2: If you're also worried about the private key possibly being
compromised due to length of time in service, here's what you do:

a: Create an entirely new CA IMMEDIATELY, and only issue new end entity
certificates from that CA.

b: Keep your old CA around until it expires, and keep issuing Revocation
information on those certificates.

c: Distribute out the new CA Certificate from (a) to your relying parties.

If the lifetime of the CA is now less than the remaining validity of the
end entity certificates, I would strongly suggest, if possible, that you
do option 1. Otherwise, you're sort of stuck.

All of the above is possible using your fairly normal OpenSSL CA commands.



> More detailed, and for addressing my actual problem right now, I'd need
> to know
> - Is it possible to renew a CA cert that way, that those user certs
> which I signed with the old CA cert shortly (means less than one year)
> ago, still remain valid?

This depends on:

1: If you do (1) above, if you give the relying party the new signing CA
certificate

2: If you do (2) above, if the client actually checks for CA certificate
validity (you'd be amazed at the number that don't :)

>   - if yes, how would I manage this using the good old openssl commands ?
>

I'm not sure I understand - as I said above, there is no such thing as
technical renewal. The only thing that a CA can do is Sign and Revoke.
So everything else is just a function of that. And since your running a
CA and issuing and revoking certificates, I can probably safely assume
that you know how the commands sign and revoke certs :)

> - I assume I have to replace the old with the new CA cert on every
> client machine where it is installed, as long as I don't set up a web
> based (e.g. url-fetching) mechanism - correct?
>
Even if you set up a "web based" mechanism, you'll still have to go
around to every client and install that certificate into their trusted
root or trust anchor store. If you don't have to do any specific action
to do this on any of your platforms, I would look at them somewhat
suspiciously, because that means that any certificate presented with an
AIA field that is followed will be trusted.

> Your help is GREATLY appreciated - and thanks a lot in advance.
>
Hope that helps.

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: own Certificate Authority: Renewal of CA cert

Andreas Grimmel
Hi Patrick,

thanks a lot for this whole lot of useful information. Now let me see if I got you right:

Patrick Patterson schrieb:
<snip>
- First of all, is there any HowTo that deals not only with creaton, but
also with the renewal of self-signed CA certs in detail?

    

That depends on what you need to do by policy for renewal. There is no
such thing as "technical renewal" - there is only policy based. Since
this sounds like an ad-hoc CA without a formal Certificate Policy, you
have some choices:
  
As I must admit, I never heard or thought of a certificate policy. Does this mean a policy, set up by e.g. my company, that defines how to enroll certificates in general, or is that something what has to do with openssl itself?
However, you're right, we're talking about an ad-hoc CA for these terms.
1: Assuming that you've got a sane key length (RSA 1024 or greater),
just create a new, self signed certificate with a new validity period
and the exact same name as your old one. That way, you'll be able to
just keep issuing CRL's with the same keys, and nothing will break.
You'll have to distribute out the new certificate to your relying
parties, but you'll have to do that no matter what you do.
  
Great - this is where I was stuck.
I have a CA key which is 2048 bytes in length, and I wouldn't be too afraid about it being compromised, since it is on duty for 4 years now, and the certs are used only for machines used within my company, so I'd say this is no big deal.
So the only thing to do is create a new CA cert using this same key and the same credentials like ST, CN, and so on and enroll it to every client.
The Clients just reload their software to recognize the new cert, and will just go on working as before.
2: If you're also worried about the private key possibly being
compromised due to length of time in service, here's what you do:

a: Create an entirely new CA IMMEDIATELY, and only issue new end entity
certificates from that CA.

b: Keep your old CA around until it expires, and keep issuing Revocation
information on those certificates.

c: Distribute out the new CA Certificate from (a) to your relying parties.

If the lifetime of the CA is now less than the remaining validity of the
end entity certificates, I would strongly suggest, if possible, that you
do option 1. Otherwise, you're sort of stuck.

All of the above is possible using your fairly normal OpenSSL CA commands.

  
OK, that would mean to not only replace the CA cert, but also the individual client cert on every client machine. Since I have to touch the client machine in both cases, my advantage here would simply be to have a new CA key, and nothing else, right?

<snip>
2: If you do (2) above, if the client actually checks for CA certificate
validity (you'd be amazed at the number that don't :)

  
This means even if the CA cert has expired, it's possible that some clients would continue working until their own cert's expiration day has come?
This is kind of funny... ;-)

  
  - if yes, how would I manage this using the good old openssl commands ?

    

I'm not sure I understand - as I said above, there is no such thing as
technical renewal. The only thing that a CA can do is Sign and Revoke.
So everything else is just a function of that. And since your running a
CA and issuing and revoking certificates, I can probably safely assume
that you know how the commands sign and revoke certs :)
  
Yes, this will be no big deal, now knowing that a renewal in technical terms just doesn't exist.
But, If you allow me to ask this one more thing, I found this command somewhere in a forum:

openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem -signkey private/cakey.pem

- in my understanding, this command takes the old cert, changes the validity to four more years (1460 days), and generates the new cert signed with the same old private/cakey.pem - somewhat logically. But:
opposite to that, *I* would have used this command, as I did when creating the original (old) CA cert:
openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem
- means to just create a new cert using the same old private/cakey.pem again.

As I can see, the only difference would be that in the upper command, I probably don't have to enter the ASN1 DN credentials like CN/ST and so on again, since this would be taken from the old cert
Am I correct here?
  
- I assume I have to replace the old with the new CA cert on every
client machine where it is installed, as long as I don't set up a web
based (e.g. url-fetching) mechanism - correct?

    
Even if you set up a "web based" mechanism, you'll still have to go
around to every client and install that certificate into their trusted
root or trust anchor store. If you don't have to do any specific action
to do this on any of your platforms, I would look at them somewhat
suspiciously, because that means that any certificate presented with an
AIA field that is followed will be trusted.

  
Right, that would really be kind of suspicious - it was just an idea of being lazy and not needing to touch every client ;-)

  
Your help is GREATLY appreciated - and thanks a lot in advance.

    
Hope that helps.
  
it did - lots of.
Thanks again for this whole lot of useful information.

Yours,
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: own Certificate Authority: Renewal of CA cert

Larry Bugbee-2
On Mar 24, 2008, at 9:28 AM, Andreas Grimmel wrote:
I found this command somewhere in a forum:

openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem -signkey private/cakey.pem

- in my understanding, this command takes the old cert, changes the validity to four more years (1460 days), and generates the new cert signed with the same old private/cakey.pem - somewhat logically.

No, that command resigns the cert but all the identity and expiry info is identical.  You will need to create a fresh CSR with the same identity info to get a new expiry.

But: opposite to that, *I* would have used this command, as I did when creating the original (old) CA cert:
openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem
- means to just create a new cert using the same old private/cakey.pem again.

As I can see, the only difference would be that in the upper command, I probably don't have to enter the ASN1 DN credentials like CN/ST and so on again, since this would be taken from the old cert
Am I correct here?

No.  The first command just resigns the cert.  Its expiry remains unchanged.  Use the second command and be sure to type exactly what was on the old cert.  Confirm with a -text.  Test.

Reply | Threaded
Open this post in threaded view
|

Re: own Certificate Authority: Renewal of CA cert

Andreas Grimmel
Well again folks, thanks once more for your comprehensive help.

Larry Bugbee schrieb:
On Mar 24, 2008, at 9:28 AM, Andreas Grimmel wrote:
I found this command somewhere in a forum:

openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem -signkey private/cakey.pem

- in my understanding, this command takes the old cert, changes the validity to four more years (1460 days), and generates the new cert signed with the same old private/cakey.pem - somewhat logically.

No, that command resigns the cert but all the identity and expiry info is identical.  You will need to create a fresh CSR with the same identity info to get a new expiry.

But: opposite to that, *I* would have used this command, as I did when creating the original (old) CA cert:
openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem
- means to just create a new cert using the same old private/cakey.pem again.

As I can see, the only difference would be that in the upper command, I probably don't have to enter the ASN1 DN credentials like CN/ST and so on again, since this would be taken from the old cert
Am I correct here?

No.  The first command just resigns the cert.  Its expiry remains unchanged.  Use the second command and be sure to type exactly what was on the old cert.  Confirm with a -text.  Test.


Reply | Threaded
Open this post in threaded view
|

Re: own Certificate Authority: Renewal of CA cert

Steffen DETTMER
In reply to this post by Andreas Grimmel
Hi,

in short I think in your -signkey command you need to add
-enddate.

* Andreas Grimmel wrote on Mon, Mar 24, 2008 at 17:28 +0100:

> > That depends on what you need to do by policy for renewal.
> > There is no such thing as "technical renewal" - there is only
> > policy based. Since this sounds like an ad-hoc CA without a
> > formal Certificate Policy, you have some choices:
> >  
> As I must admit, I never heard or thought of a certificate
> policy. Does this mean a policy, set up by e.g. my company,
> that defines how to enroll certificates in general, or is that
> something what has to do with openssl itself?  However, you're
> right, we're talking about an ad-hoc CA for these terms.

The policy is the definition how the people (roles) that are able
to access (use) the secret/private CA (and other) keys have to
use those keys, which usually includes certification and thus
clear statements which certificate signing requests to sign, how
to prove their authenticity, how to distribute them, what to do
with CRLs etc

> So the only thing to do is create a new CA cert using this same key and
> the same credentials like ST, CN, and so on and enroll it to every client.
> The Clients just reload their software to recognize the new cert, and
> will just go on working as before.

Yes, I think you will need to update the certificate(s) on each
client if expiry dates are checked (I guess on PC Apps this
probably is done in almost any case).

> OK, that would mean to not only replace the CA cert, but also the
> individual client cert on every client machine. Since I have to touch
> the client machine in both cases, my advantage here would simply be to
> have a new CA key, and nothing else, right?

I think in your case, 4 years ago you missed to use a lets say 20
year validity of the CA cert. So I think now I wouldn't change
the keys at all, just change the certificates (or its
information).

> This means even if the CA cert has expired, it's possible that
> some clients would continue working until their own cert's
> expiration day has come?
> This is kind of funny... ;-)

I think this depends on the application. Usually I would expect a
CA not to sign for time intervalls exeeding the CA certificates
validity.

> Yes, this will be no big deal, now knowing that a renewal in technical
> terms just doesn't exist.
> But, If you allow me to ask this one more thing, I found this command
> somewhere in a forum:
>
> openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem -signkey
> private/cakey.pem

You probably want something like `-days 7300' and also `-enddate'
is needed I think, so maybe something like:

  openssl x509 -in cacert-old.pem -days 7300 -enddate -out cacert-new.pem -signkey private/cakey.pem

> - in my understanding, this command takes the old cert, changes the
> validity to four more years (1460 days), and generates the new cert
> signed with the same old private/cakey.pem - somewhat logically. But:
> opposite to that, *I* would have used this command, as I did when
> creating the original (old) CA cert:
>
> openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem
>
> - means to just create a new cert using the same old private/cakey.pem
> again.
>
> As I can see, the only difference would be that in the upper command, I
> probably don't have to enter the ASN1 DN credentials like CN/ST and so
> on again, since this would be taken from the old cert
> Am I correct here?

You may try it. The generated certificates can be viewed using

openssl x509 -text -in cacert-new.pem

I would not use `req -new', because maybe you accidently changed
something in openssl.conf and you get a different CA cert. Of
course this shouldn't happen because the policy should state the
details but if you don't have one ;)
At least I would expect that the certificate has a different
serial number.

with `-days 7300 -enddate -signkey' I would expect the same cert
(except end date, hash, sig of course)

> Right, that would really be kind of suspicious - it was just an idea of
> being lazy and not needing to touch every client ;-)

I'm afraid you need to update each because they check against a
local copy of the CA certificate(s).

oki,

Steffen
 
About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]