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

* 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

> 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

> 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).



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 openssl-users@openssl.org
Automated List Manager majordomo@openssl.org