7

Background: I have my own authoritative certificate that I generated myself for signing certificates for services my friends and I use, including web server, ircd, etc. It's convenient because I don't have to spend money getting my certificate signed and among my those who use it, the guarantee of security is fairly complete.

Caveat: Being somewhat noobier then than I was now, I set my CA to expire after a year. This was about 10 months ago. The private key is 4096 bit RSA and the certificate is self signed with SHA512, so it should stay secure for pretty much as long as I'm around to care about it, as long as I don't lose the private key.

Question: I know I can generate a new certificate from the private key with a longer expiration date (say 100 years from now for the purposes of this discussion). Would the replacement be as simple a process as substituting the newly generated, extended certificate to all of the clients? Would they accept the subcertificates as trusted, provided they updated their stored copies of the CA to reflect the new expiration date? Would I be able to skip regenerating all of the intermediate certificates as long as the CA's keypair and fingerprint remained the same?

Improve this question
1
  • It's more or less an academic issue because most of the subcertificates expire after one year as well, and I won't bother resigning the original private keys, I'll just generate new ones
    – Wug
    Commented Jul 17, 2012 at 19:28

3 Answers 3

Reset to default
5

You shouldn't have to reissue all of your certificates. Assuming that each is still valid, and as long as you use the exact same key and subject for your CA you should be able to extend the life of your CA and redistribute the certificate as the new trust anchor.

Improve this answer
4
  • I was just about to come back and mention that I have forgotten to update the CA on my windows partition, so locally I still have the old one, but the new (extended) one is installed and working on the web server box.
    – Wug
    Commented Jul 17, 2012 at 23:54
  • 2
    Same key, subject and issuer (always equal for a root), and also serial if you used the issuer&serial form of AKI in any child cert(s). Also, for now I suggest not going beyond 2037 because some systems may not yet have fixed 32bit-time bugs, or 2050 because it involves different ASN.1 encoding where bugs may lurk.
    – dave_thompson_085
    Commented Jan 28, 2015 at 8:35
  • This was kind of referenced by dave_thompson_085, but the key identifier (KI) is really important. If you reissue any CA cert with the expectation of not having to invalidate the certs it has already signed, there are three critically important fields to retain from the original cert: the public key (needed to validate the certs already signed, and to issue CRLs), the subject (must match the issuer of signed certs), and the subject KI. There's no need to recalculate the KI, just set it as identical to before. It just needs to match the authority KI in the already signed certs.
    – Lampshade
    Commented Sep 13, 2018 at 13:10
  • Also, if the already-issues certs contain a URI to the CA cert in authority access information, it's a good idea to ensure that the newly issued CA cert can be downloaded from the same location, either by identically naming it or using some redirector.
    – Lampshade
    Commented Sep 13, 2018 at 13:11
0

The Answer is Yes. You can modify the CA without re-issue the certs issued by the particular CA But there are certain parameters you need to restrict. 1)Normally to verify the digital signature of the chain CA, your public key is needed. So without changing the Keypair you can do. 2) After doing the changes , you need to distribute the modified CA to where your using as it needs to trusted by the other clients. 3) Check for the application level or configuration level for fingerprint details ( needed for certain checking) in case you have stored anywhere.

Improve this answer
0

Regarding the same common Name for CA is Yes. You can use the same common name as long as the key is different. The reason why its mostly not preferable is that the most of the security product doesn't verify with respect to common name and key as they are checking with respect to name and this is wrong as per RFC standard.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .