2

I am in the process of extending the lifetime of a private CA creating a new certificate with the same name, serial number, private/public keys, etc. The only change would be the "startdate" and "enddate".

Checking certificate chain verification, it is successful verifying an old X.509 certificate using the new CA, using OpenSSL. Cool.

But I wonder... the startdate of the new "equivalent" CA is more modern that the "startdate" of the X.509 certificate I am verifying. This would mean that the CA was not valid at the time of the X.509 certificate signing.

OpenSSL verifies that all the certificates in the certificate chain are valid "now", but it doesn't check "causality" between signatures in the certificate chain.

This is OK for OpenSSL, but I wonder if I would find issues with other X.509 libraries out there.

Checking RFC 5280 I see that chain validation is quite complex and not trivial, but the only time reference is this:

6.1.3. Basic Certificate Processing
...
  (2)  The certificate validity period includes the current time.
...

That is, all certificates in the chain must be valid "now", but causality between certificate signatures is not described at all.

So...

Am I safe doing what I am doing when dealing with other non "OpenSSL" implementations?

Improve this question

1 Answer 1

Reset to default
1

It is not something uncommon when you have multiple CA certificates with same Subject and Public Key and different times. Here is a picture from the internet that shows such scenario:

enter image description here

If validation function has access to both (or multiple if any) CA certificates, it will build a separate chain for matching issuer and validate each independently. If we look to an image, then the following chains will be constructed:

  1. Server cert -> LE Authority X3 -> ISRG Root X1
  2. Server cert -> LE Authority X3 -> IdentTrust DST Root CA X3

Your scenario is very similar to LE Authority X3 intermediate certificate. When all chains are constructed and validated, validation engine performs "best" chain selection based on certain criteria. In your case, for some time one chain will be valid and second will be invalid, so best chain selection is easy: validation function will use valid chain and discard invalid.

If validation function produced multiple valid chains, the function applies additional logic (or weights) in order to select "best" chain among multiple valid chains. That is, if validation function has access to both, valid and not-yet-valid issuers, then you shouldn't face any issues, because validation function will return a chain with valid issuer to the caller.

UPDATE: it seems I didn't clearly understood the question which was about:

Is out there any problem if a CA "not before" is later that the "not before" of a certificate it signed?

it depends. If current (validation) time is within certificate's validity period, then it is considered time-valid. Let's say, you set CA validity from Apr 1, 2024 to Apr 1, 2025 and signed certificate is valid from Mar 19, 2024 to Jun 1, 2024, then validation result will depend on when you run this validation.

  1. You execute validation on Mar 20, 2024. Current time is within leaf cert's validity period. Leaf cert is ok. Current time is outside of issuer's validity period. Not all certificates are within their validity periods, chain is not time-valid and certificate validation function should fail.
  2. You execute validation on Apr 2, 2024. Current time is within leaf cert's validity period. Leaf cert is ok. Current time is within issuer's validity period. Issuer is ok. All certificates are within their validity periods, entire chain is time-valid and validation function can proceed with other checks if necessary.

That is, retrospective certificate's time validity isn't checked at all. What matters -- if all certs are within their validity periods at validation time point. What was in the past -- no one cares.

And just to reiterate: it is valid scenario when leaf certificate's NotBefore is earlier than issuer's NotBefore or NotAfter is after issuer's NotAfter times. Leaf certificate contains only references of matching issuer cert, such as public key hash (via SKI extension) and Issuer field. No one prevents you to have multiple certificates with same public key (and hash) and Subject field. It happens all the time when you renew CA certificate with same key pair. During renewals, only serial number and validity periods are changed. Public key and Subject of the issuer is not changed.

Improve this answer
8
  • Thanks for your comment, but I think you are not replying the original question about signature timestamps and overlap of lifetimes of the different certificates in the chain.
    – jcea
    Commented Mar 19 at 12:36
  • There is no indication about signature timestamps in OP question, or I missed something? Certificate signatures are not timestamped.
    – Crypt32
    Commented Mar 19 at 13:39
  • My original question is about this: Is out there any problem if a CA "not before" is later that the "not before" of a certificate it signed? That would mean that the current CA certificate was not the certificate that originally signed the signed certificate?. Lets say, my "jcea.es" certificate has a "not before" of January 1st, but the CA signing it has a "not before" of "june" and we are in august. It is clear that that certificate was not the one signing the "jcea.es"
    – jcea
    Commented Mar 19 at 15:03
  • ` Is out there any problem if a CA "not before" is later that the "not before" of a certificate it signed?`, not if CA cert is within validity period at the validation time.
    – Crypt32
    Commented Mar 19 at 15:10
  • @jcea I've updated my response based on your comments. I hope it answers your question.
    – Crypt32
    Commented Mar 19 at 15:22

You must log in to answer this question.

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