So I have a client-authencation cert installed on client PCs, which doesn't expire for 5 more years. Unfortunately, the cert on our gateway which is used to validate the client cert, expires this month.
I know.... D'Oh!

Plan A is to place a new cert on our gateway, and issue new client-auth certs to all of the clients. This is going to be very disruptive.

It seems like it would be simpler to place a new cert on our gateway, and have it continue to validate the client certs until the client certs actually expire in 2019. This would be my proposed "Plan B".

Is Plan B valid? i.e. can you have a new cert on the gateway, honoring existing certs, or do you have to re-generate everything "top-down"? I guess I'm asking if you can replace a link in the trust chain, without breaking the chain.

I'm sorry that this is over-simplified. I don't really understand all of this, but am struggling to find a loophole here that we can leverage.

These certs are generated internally (our own CA) and are not used for SSL. Only client-auth, attached to SOAP messages, within SSL (SSL isn't expected to change).

Thanks, Chris

  • Are the client certs signed by the gateway cert, or signed by a central CA that is not expiring yet?
    – David
    Jul 16, 2014 at 21:17

2 Answers 2


Sorry, but the answer is "no". The top level root certificate "signs" your other certificates. When your client goes to validate their certificate, they are going to look at the signature on it, and they will see it was signed by "oldcert", they will then attempt to validate "oldcert", and discover and that "oldcert" has expired. Just having the new certificate doesn't mean anything.

You could take the same "certificate signing requests" that were originally used to get the certificates signed with your old cert, and submit them to the new certificate server and request new signatures. (There are a few risks, you might duplicate an ID or something). But then you still have to distribute the new certificates.

Lesson to take away: when signing a certificate, make sure that it expires before the root certificate expires.

  • If the new certificate has the same public key and DN as the old one, then the substitution should work. Jul 18, 2014 at 12:50

You can "regenerate" the certificate on your gateway, but it will work only if you take care to reuse the same name and key.

This is a certificate chain: the certificate on the gateway is the "CA certificate" and the clients have been issued certificates by that CA. Such a client certificate will be deemed valid (aka "acceptable") if whoever does the verification can build a valid chain. Conditions are listed here (don't go read that, it will destroy your sanity); they mostly boil down to:

  • The subjectDN of the issuer must match the issuerDN of the issued certificate.
  • The current date must lie between the notBefore and notAfter date of each certificate.
  • The signature on the issued certificate must be successfully verified with regards to the public key in the issuer certificate.

The consequence is that if you produce a new CA certificate (for your "gateway") with a longer validity range, and take care to use the exact same name and the exact same public key, then the new certificate will work as a replacement for the old one.

A further complication is that whoever will have to validate the client certificate will need to access the new CA certificate instead of the old one. Possibly, the client may send it along as part of the protocol (this happens in some protocols, e.g. SSL: when the client sends its certificate, it actually sends a complete chain), but this will require client systems to know it. Any certificate may contain a link (URL) to a place from which the issuing CA certificate may be downloaded (it is called Authority Information Access); if that is the case, then you will want to put your new CA certificate at that exact place, replacing the old one.

Summary: your "Plan B" may work, but only if you reuse the same name and key in the new certificate, and it may depend on the exact usage scenario. Your CA software may be troublesome if it insists on generating a new key pair.

Note: some CA avoid this situation by enforcing nesting of validity dates: if a CA's certificate ends on December 13th, 2014, then it will refuse to issue certificates with a notAfter date beyond December 13th, 2014. Microsoft's CA (Active Directory Certificate Services) is of that kind. I take it that your CA software does not apply that rule.

  • thanks for the glimmer of hope! I'll have our web ops people look at it. Jul 18, 2014 at 14:54
  • If the child cert uses the issuer&serial form of AKI (as opposed to the keyid form) the new parent must also have the same issuer and serial. If the parent is a root, as trust anchors usually must be and DIY CAs often are, making subject the same already makes issuer the same. But duplicated serial may cause trouble in some software. Jul 19, 2014 at 5:13
  • Actually, key identifier matching is not mandatory for validation. A chain where everything is right but key identifiers don't match is still valid as per X.509 rules. The key identifiers are meant as a helping tool for path building, not as a rule to be enforced. Jul 19, 2014 at 11:30

You must log in to answer this question.

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