Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

For my computer to verify the identity of a certain certificate should it have all the certificates up to the root certificate?

share|improve this question

3 Answers 3

Certificate validation requires processing a whole chain from a trust anchor (a "root certificate") down to the certificate which is to be validated. So your computer must have the intermediate CA certificates at some point.

This does not mean that your computer must store those CA certificates. Protocols which handle certificates usually include some provisions to also convey a bunch of "helper objects" which include intermediate CA certificates. For instance, in SSL/TLS, the server sends its certificate along with a bunch of other certificates which are supposed to be the intermediate CA certificates that the client may use to validate the server certificate. So the client has access to the needed CA certificates right when it needs them.

It is still a good idea to keep a local cache of intermediate CA certificates, especially on modern computers where storage is cheaper than network bandwidth.

share|improve this answer

According to RFC 2549 section 3.2, under X.509 a the certificate authority (CA) that signed a server certificate may already be stored on the client computer--if it is not, the CA's certificate will need to be signed by another CA, and so on, until the chain reaches a CA whose public key is stored on the client computer. That one is generally a root certificate.

Under most X.509 implementations, however, there's nothing to stop you from storing a self-signed certificate, or one otherwise not connected to a "root CA" like Verisign, and using that to verify the server's authenticity thereafter.

share|improve this answer
    
say certificate certA needs to be verified. Do i need to mark all the certificates between the root and certA as trusted ? –  user1157 Jan 24 '11 at 15:48
1  
As described in section 6 of the RFC, when the hierarchical system's working properly you don't need to manually intervene to trust anything; you will have a chain of certificates starting with one you already trust, and each verifiably trusting the next one down 'til you reach the server in question. –  user502 Jan 24 '11 at 19:24

OK, there's a long answer:

  • The easy way - if you are only checking that the certificate came from a trusted issuer, then you only need the collection of CAs that may be issuing certificates for you. This approach is quick and easy, but it eliminates typical best practices, like certificate status checking.
  • The right way - where there is a higher risk or requirement for better checking the site should (at a minimum) - rebuild the certificate path, check every certificate EXCEPT the root against a certificate status mechanism (CRLs or OCSP), verify validity date of every certificate.

If you want to do it the right way, you should have every CA that is involved in building any certificate that could be used for issuing certificates used for authentication. When I say "rebuild the certificate path", I mean check that the signature on the certifiate matches up with the public key of the issuer, and the signature of the issuer matches with the public key of it's issuer and so forth until you hit a root certificate where its signature matches its own public key.

You should NEVER need to store the end entity certificate.

share|improve this answer

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.