What happens to code sign certificates when when root CA expires?

Question

So far clear for me: If the code sign certificate itself expires, signed code will be verified/accepted in case it was signed with a time stamp. If not, the signed code is expired too.

But what happens if my CA itself expires (root CA an thus issuing CAs)?

• Will code still be accepted if it is timestamped?
• Must the expired Root and Issuing CA certificates still be present (e.g. in the trusted root ca certificate store)? This is my assumption, even though the CA may be demoted, the client that executes the signed must still trust the CA? Otherwise the trust chain will be broken, right?
• Will the lack of a CRL or AIA pose any problems?

Solution

But what happens if my CA itself expires (root CA an thus issuing CAs)?

Literally, nothing. Let's explain it a bit in more details.

If the signature is not timestamped, the signature is valid as long as:

• data is not tampered
• signing certificate is time valid
• neither certificate in the chain is revoked
• root certificate is trusted

Once signing certificate is expired, revoked or become invalid in one or another way, the signature is considered invalid. Plain and simple.

The purpose of timestamps in digital signature is to provide an extended trust for signed content. Signing certificates are valid for a short period time and basic trust settings are not suitable for long-term (maybe, archived) signing. Normally (without timestamps), you will have to recreate the signature each time signing certificate is renewed. It is a way to nowhere.

By adding a timestamp to digital signatures, trust conditions are changed to the following list:

• data is not tampered
• signing certificate *was* time valid at signing time: signing time is within signing cert's validity
• Neither certificate was revoked *before* signature generation
• both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store).

What changed here: signature remains valid after involved certificate expiration. That is, entire chain for signing and timestamp certificates may expire (along with root certificate) and it won't break the trust. Certificates in the chain can be revoked. The only requirement: if any certificate is revoked, revocation time (it is obtained from CRL) must be set to a time after the signature is created (signing time is identified by a timestamp). Previous sentence means that there must be a signed CRL to prove that neither certificate was revoked at signing time.

This is the reason why modern Windows systems ship a long ago expired root certificates. They are still used to validate old signatures and which are timestamped.

A while ago I wrote a blog post that explains the subject in more details: Digital signatures and timestamps

Comments

[ThoriumBR]

Your blog post is a very good article on the subject!

[Crypt32]

I found this topic very confusing across IT Pro (and developers) and tried to sort things out in a blog post.

[dr_pepper285]

But the point with the CRL is not totally clear to me. So i do need still have the (last) CRL of the expired CAs available?

[Crypt32]

Yes, CRLs are required. Not necessary last, it must be published (ThisUpdate field) after signing time. This CRL can prove that neither certificate in both chains (signing and timestamp) was revoked at signing time.