Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 0 down vote favorite

I have the following situation:

  • A server certificate (CServ) is signed by self-signed certificate (C0)
  • A client certificate (CCli) is signed by CServ
  • Client's trust-store contains C0, so the client application can trust CServ

Note: C0 is actually a simulation of a CA certificate for testing purposes.

Now, let's consider a situation when C0 either is expired or not yet valid. Since it's stored in client's trust-store, is it still trusted? In other words is chain [C0, CServ] still valid?

share|improve this question
Do you validate according to chain or to shell validation model? This can give rise to different answers to your question. The fact that you issue client and server certificates, admittedly points toward shell in which case the chain is not a chain of currently valid certificates and thus not to be trusted for current use. – mkl Jan 14 at 7:24
Unfortunately, I'm not familiar with the term "shell validation model". If you speak about technical side of validation, the certificates are managed by a Java application, thus we use chain validation here. – Andrey Atapin Jan 14 at 7:33
2  
Shell and Chain are different validation models for the certificate chains of signatures, and your question deals with validation of certificate chains. You mention a simulated CA but don't explain the kind of CA being simulated. Thus I cannot be sure which validation model applies in your use case. That being said, you seem to be talking about certificates meant for securing client-server communication, and in that case the shell validation model most likely applies, and this model required that all certificates must be valid and not expired at the time of verification. – mkl Jan 14 at 10:26

1 Answer

up vote 2 down vote accepted

The trust store seems to contain certificates, but that's an illusion (or a tradition). Technically, a trust anchor, i.e. the basis for the trust in certificate validation, is a name coupled with a public key. It so happens that people found it convenient to store the name and public key as a file with the same format as a certificate; this required some trickeries, such as the "self-signature", which makes no sense but had to be included because the format for a certificate includes a non-optional field for a signature.

At that point, it really depends on the OS/browser internal conventions. Some implementations will look at the "validity dates" in the trust anchor "certificate" and will use them as, indeed, validity dates (i.e. beyond the end of validity date, they will cease to trust that trust anchor, even if it is still "there", in the dedicated store for trust anchors). Some other implementations will ignore these dates altogether. It is really up to each implementation to make these choices, since the standard is silent on the subject.

So you have to test.

share|improve this answer
I was looking for word of the standard, but couldn't find one in a bunch of PKI related standards. Thanks. – Andrey Atapin Jan 15 at 6:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.