0

If you want to set up a service that is signed using some Certificate Authority system (SSL/TLS, certain configurations of IKE, etc), if you want to use a self-signed certificate (e.g., for testing), you generally have to create a certificate, a CA certificate, sign the first using the second, and then install the CA certificate's public key as trusted in your client configurations.

I'd think that it'd be just as secure to just trust the non-CA certificate directly. Why the more complicated setup? Is this a consequence of the fact that these systems are designed to work with a CA hierarchy, or is there some more specific reason?

Improve this question
3
  • "just as secure" is a vague term. Secure from what? Is the communication encrypted just the same? Yes. But there is far more to the CA infrastructure than just the encryption of a stream.
    – schroeder ♦
    Commented Dec 9, 2015 at 17:30
  • I mean just as secure to the extent that you'll be connecting to this one particular pre-trusted server. In either case - trusting a CA that signs the cert or trusting the cert itself - the end result is that you trust the cert.
    – joshlf
    Commented Dec 9, 2015 at 18:09
  • 3
    A self-signed certificate is its own CA. When you create a self-signed certificate, you sign it using its own private key. Then you put it in your list of trusted CA certificates. Done. Certificate trusted directly.
    – Jonathan Gray
    Commented Dec 10, 2015 at 3:32

2 Answers 2

Reset to default
0

I think you answered you own question:

Is this a consequence of the fact that these systems are designed to work with a CA hierarchy?

Yup. In the X509 Certificate model, Root Certificates (or "CA Signing Certificates") have the basic constraint CA:True which allows it to sign other certificates. By putting the root cert into your trust store, you automatically trust every cert that they sign (and certs signed by subCAs signed by that root CA cert) so with only one cert in your trust store, you automatically trust a whole hierarchy of CAs and certificates - even ones you've never seen before. Otherwise you'd have to manually add every single non-CA cert to your trust store and it would very quickly become a memory and disk space hog, and the problem of how to trust a new certificate that you've never seen before becomes a lot more complicated.

As pointed out by @JonathanGray in comments, a self-signed cert might be what you're looking for since it's both a root CA and an end-user at the same time. Though it doesn't solve your original problem of having to do multiple setup steps.

I'm not aware of any technical reason why you would be blocked from putting a non-root cert into your trust store, except that it would have to be programmed to look for that. Since that use-case only makes sense in dev environments I'm guessing that most software vendors wouldn't bother to spend time writing that code.

In more detail, the trust-store step of certificate validation works like this: suppose you are validating an SSL server cert, look at the CA who signed this cert and see if they are in your trust store, if not, look at the CA who signed that and see if they are in your trust store, and so on until you either find one, or hit the top of the chain. Most software probably wouldn't bother looking for the end-user cert in the trust store just because you're wasting the runtime of an expensive search on something that should never happen in a production system anyway.

Improve this answer
0
1

Depends what you are testing. According to wikipedia:

a CA is a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.

So if you want to test the real world scenario where there will be a CA, then it would be better to create a "test CA" and have that sign your self signed "test Certificate". This would test out the CA trust infrastructure.

Trusting the self signed certificate will also work but it is not simulating the real world scenario. If your testing scope does not require you to test the CA trust chain, then you can trust just the self signed certificate.

Improve this answer
1
  • In particular if your app is trusting based on certs it needs to stop trusting when a cert is revoked, and you can't test that functionality with manual direct trust.
    – dave_thompson_085
    Commented Dec 10, 2015 at 10:14

You must log in to answer this question.

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