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.

I'm getting conflicting information and it seems people are using certificates a little differently depending on how much effort they want to expend in managing them, and maybe the application being used.

Client certs aside, this is my understanding: A server has a signed certificate from a CA. A client should include only the CA's intermediate and/or root certificates in it's Trusted Authority (store depends on application of course). As long as any new or renewed host certificate still uses the same roots the client doesn't need to worry about changes to the server's certificate.

FTP partners I deal with are updating or changing their server certificates and sending them to me. I see many implementations of clients just adding the server certificates to the Trusted Authority. From what I (think I) know, this not only gives me more to manage when these certs expire (annually), but I lose the benefit of CRLs (or do CRLs only work for OSes and browsers?) I thought you only add self-signed certs to Trusted Authority stores.

So, am I right to only want to add roots and intermediates to Trusted Authority stores, or do I get some benefit of adding each server certificate? Does this really matter and it's just preference?

share|improve this question
add comment

2 Answers

To answer your question, it is OK (from a security perspective) to add the server cert to your trusted store. You can add either the CA cert, or the server cert itself.

The primary tradeoff has to do with manageability, not security. You explained some of the manageability issues well.

If the server's cert is signed by a well-known CA, the normal thing to do would be to add the CA cert to your trusted store. However, it is possible that your correspondents may be using self-signed certs that are not certified by any CA. In that case, adding the CA to your trusted store is not an option, and you may be forced to add their server cert to your trusted store.

share|improve this answer
    
Thanks, DW. Nice to know I'm not crazy. –  Mike Sep 9 '12 at 18:24
add comment

Your chain of trust has to be anchored in a trusted certificate somewhere. Adding the "root" certificate (whichever that may be) is enough to establish that trust. However, if any chaining certificate which links the server cert to the trusted one is not sent by the server during the connection, and your client doesn't have a copy of that chaining certificate, then the full chain of trust cannot be established.

So in that case, adding the intermediate certificate would help. The server's own certificate is always sent during SSL negotiations, so trusting THAT certificate simply anchors the trust right there, obviating the need to validate down to some other trusted authority and potentially avoiding any missing components along the way.

As for CRLs, if you directly trust the server certificate, no CRL will be consulted. Checking the CRL is up to the client software implementation, and may or may not be a supported feature.

share|improve this answer
    
Thanks, Tyler. So it's fine and/or common to just trust the server cert itself? I know I can, and I understand the chain, but I thought it best practice to only use roots and intermediates in Trusted lists. At the least I figure host certs get changed regularly, but roots and intermediates only every few years, cutting down on admin effort as well. –  Mike Sep 9 '12 at 3:16
    
@Mike you typically do not directly trust the server cert if it is signed by a trusted CA. If it is signed by a private CA or self-signed, then you follow whatever policy is set by the organization. –  tylerl Sep 10 '12 at 0:37
add comment

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.