43

When a X.509 certificate chain is composed of X1, X2 ... Xn and Xn is root CA, Can a certificate in lower level have longer validity period than its parents? I think that lower level should be proper sub-range of high level at least in practice.

While I cannot find any such obligation in RFC2459, can I rely on that assumption?

Any comments are deeply appreciated.

Improve this question
2
  • 2
    This would be an interesting area to research with current SSL implementations. I bet you'd find a couple of bugs where a valid cert with an expired parent is erroneously allowed. Although I doubt it would be exploitable in the wild.
    – paj28
    Apr 14, 2016 at 13:23
  • 5
    No, I see plenty of certs used within an organization which will be valid long after the CA certs used to verify them are expired. This happens when each cert is set to last a specific period (eg. 365 days...). The certs issued later will have a later expiration date than the issuer. They will also be useless as they cannot be verified.
    – ztk
    Apr 14, 2016 at 13:42

2 Answers 2

Reset to default
39

This is an historically disputed point.

In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann:

Although this isn't specified in any standard, some software requires validity period nesting, in which the subject validity period lies inside the issuer validity period. Most software however performs simple pointwise checking in which it checks whether a cert chain is valid at a certain point in time (typically the current time). Maintaining the validity nesting requires that a certain amount of care be used in designing overlapping validity periods between successive generations of certificates in a hierarchy. Further complications arise when an existing CA is re-rooted or re-parented (for example a divisional CA is subordinated to a corporate CA).

The Microsoft PKI ("ADCS", aka Active Directory Certificate Services) enforces validity period nesting, in that, when it issues a certificate, it will not allow the end-of-validity date of that certificate to exceed that of the current CA certificate (in effect, truncating the validity period mandated by the template if it would lead to such a situation).

Even though, when renewing a CA certificate, it is possible to keep the same CA name and CA key, in which case both the old and new CA certificates can be used interchangeably as long as neither is expired, on EE certificates issued both before and after the renewal. That is, if the old CA certificate is CA1, the new one is CA2, certificate EE1 was issued before the renewal and certificate EE2 was issued after, then CA1->EE1, CA1->EE2, CA2->EE1 and CA2->EE2 should all validate; this is very convenient to ensure smooth transitions. While the validity period nesting implies that CA1->EE1 and CA2->EE2 will nest, CA1->EE2 and CA2->EE1 might not nest -- and this is fine.

Summary: you cannot rely on validity period nesting, and you should not try to enforce nesting when validating certificates.

Improve this answer
6
  • 3
    +1 a better answer than mine :-)...."and you should not try to enforce nesting when validating certificates." .. I assume you mean don't check validity nesting explicitly, but still fail if one in the chain is already expired?
    – Mike Ounsworth
    Apr 14, 2016 at 13:40
  • 2
    @MikeOunsworth: yes -- that's what Peter Gutmann calls "pointwise checking".
    – Tom Leek
    Apr 14, 2016 at 14:22
  • Many thanks for kind answer! I think each pair should have overlapping validity period: CA1->EE1, CA1->EE2, CA2->EE1 and CA2->EE2. is it right?
    – Chul-Woong Yang
    Apr 14, 2016 at 16:32
  • @cwyang: each pair may be valid only at dates that fall within the validity ranges of all involved certificates, so yes, some overlapping is needed. Considerable overlapping is common upon renewals, to give time for smooth transitions.
    – Tom Leek
    Apr 14, 2016 at 19:39
  • The important thing is that the CA certificate was valid when the CA certificate signed the CSR, and that the signed CSR is valid at the time it was presented as part of the handshake. The same logic applies to digital signatures, which is exactly what this is.
    – user207421
    Apr 14, 2016 at 22:34
17

Hmm, I agree that I would have expected to find this info in RFC 5280 4.1.2.5. Validity. (By the way, RFC 5280 obsoletes RFC 3280, which obsoletes RFC 2459, so you really shouldn't be looking at 2459 any more).

That said, you can figure this one out logically (at least for a standard TLS-like setting): When an end-user validates a cert, they have to follow the chain up to the root, ensuring that every cert along the way is valid. Let's say that X2 expires before X1 (and assume that X2 was the issuer for X1). Once X2 expires, X1 is as good as useless since there is no way to build a validation chain from X1 to Xn.

Here's a case where a CA might issue certs with a longer lifetime than the root: requirements state that A) All leaf certs must have a lifetime of 3 years (say they're going into embedded devices) B) All leaf-certs must be issued off the same root (say you only have space to pin one root). Now, the CA cert will expire in 2 years, and within that time you plan to issue a new CA cert for the same CA key. In that case there's no problem issuing a 3 year leaf-cert off a 2 year root.

The question you're asking is a little vague as to whether you're looking for the CA / issuer to enforce the "validity nesting" rule, or for the client / verifier to enforce it.

  1. If you are the CA / Issuer:: it is up to you. There are many CAs that will not issue a cert with a longer lifetime than themself. That said, I can imagine scenarios in which might want to do this.

  2. If you are the Client / Verifier: I don't think it gains you anything to be strict about this. You are intentionally causing compatibility problems between your client and CAs that don't follow "validity nesting" ... for what gain? _(assuming that all certs in the chain have to be within their validity period at the time of validation, I suppose this is what you are calling "standard validation" in your comment).

Improve this answer
5
  • Couldn't timestamps levitate this? (Just like I use timestamping in code-signing in order to make signed code usable if only the signature was valid at the time of signing) - After all the CAs are more signing requests than issuing certs. So if ROOT-CA (valid 2000-01-01 until 2015-12-31) signed MyCert (valid 2015-12-01 until 2016-11-30) on 201-12-24 (as verified by a timestamp) then checking MyCert on 2016-04-14 should still succeed, because the signing cert wsa valid at the moment of signing. - This method might cause (actual and logical) trouble in case of CA-Cert revocation though; [cont]
    – Hagen von Eitzen
    Apr 14, 2016 at 15:09
  • [cont] after all, expiry can be considered as "silent revocation" so that at the moment of checking (2016-04-14) the CA-Cert should be treted like a revoked cert, and as revocation of a compromised cert will typically happen some time after the actual compromise, it should always affect all previous signatures issued. By this logic, the timestamping I introduced becomes moot, and we are back to "all certs in the chain must be valid at the moment of checking".
    – Hagen von Eitzen
    Apr 14, 2016 at 15:11
  • @mike Thanks but I'm confused with your explanation. I think all the chain is invalidated when the root is expired since there is no trust. Did you mean the case of non-standard certificate validation?
    – Chul-Woong Yang
    Apr 14, 2016 at 16:24
  • 1
    @HagenvonEitzen I don't really follow your argument (too many words and numbers) but let's say I compromise a CA key after it's expiry, what's stopping me from issuing myself a fake cert that looks like it was was issued in the past, when the CA key was still valid? In other words: what's preventing me from spoofing a timestamp?
    – Mike Ounsworth
    Apr 14, 2016 at 18:47
  • @cwyang I see, there's a hidden assumption in your question that all the certs in the chain are within their validity period at the time you do the verification. I'll update my answer.
    – Mike Ounsworth
    Apr 14, 2016 at 18:51

You must log in to answer this question.

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