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
