3

Is it possible to have OpenSSL trust a non-root CA such that a certificate signed by that non-root CA can be properly verified? I've noticed that the default behavior for OpenSSL is to only verify certificates when it can build a complete chain, up to a self-signed root CA. Can this be overridden?

I specifically do not want the root to be in the CAfile.

Justin Gerace
  • 31
  • 1
  • 2

4 Answers4

2

Recent versions (presumably 1.0.2 and above) of OpenSSL supports -partial_chain option. http://wiki.openssl.org/index.php/Manual:Verify%281%29

Regarding the use-case, it is for example usable in OCSP stapling (i.e. openssl ocsp command), in which case there is no merit in checking the status of the intermediate CA.

kazuho
  • 21
  • 2
  • 1.0.2 is still in beta, although with luck it will be official soon. Commandline `ocsp` does only direct relier-responder OCSP, not (either kind of) stapling; the underlying OCSP_* module could be used by libssl for stapling but isn't at least not yet. – dave_thompson_085 Jan 07 '15 at 17:40
1

OpenSSL supports either the CAfile or CApath options for CA certificates. I think you need to clarify what you mean by 'non-root CA' though as this doesn't really make sense unless you are referring to an intermediate certificate. And the idea of trusting an intermediate as if it was a root makes even less sense if you don't want to add the root that signs that intermediate to the CAfile you are using.

Chris
  • 21
  • 2
0

Woah. OK, so this is not a recommended best practice. I've had to do it, but it's generally been a night mare.

First - if you can't trust the root, you can't trust the CA chain. The root is the source of the trust, so if there's a reason to not include the root, you have a problem with the basic concept on which PKI is built - that there is a final authority that is so highly trusted that everyone can just believe in it -- and that's the root.

Next - if your case is that you trust some CAs in the hierachy but not others, you have a valid point. For example, in a case that has 2 CAs - one for human certificate issuance and one for non-human (like SSL server certs), it's a fair point that you may want your site to only provide access to one path. That doesn't make the other CA invalid, it just isn't right for the case at hand.

Generally this comes down to the difference between authentication and authorization. If you want only credentials from intermediate CA1, it doesn't mean in this case that credentials from intermediate CA2 are invalid, so they are authenticatable. But they are not authorized for this use case.

In the interest of elegance...

Many trust stores are not built for this use case, but some are. The true answer is that the elegant way is to have additional access control checking code built as a hook to the login use case that does the checking you want to make sure that all users come from CA1 not CA2. It's often considered a specialized use case.

The less elegant way...

I haven't tried this with Open SSL - but you may be able to fake it out - put the intermediate CA you want, AND the root into the trust store. Then make sure all your client requests only include the certificates below that intermediate CA.

The Open SSL code may be able to map it from there. May systems will, particularly when the client is sending a partial chain.

If you can't control the client, you may or may not be out of luck. I don't know of any system that planned for you to explicitly NOT trust the root... it runs counter to the basic premise.

bethlakshmi
  • 11,656
  • 1
  • 28
  • 59
0

Is it possible to have OpenSSL trust a non-root CA such that a certificate signed by that non-root CA can be properly verified?

Yes. You can specify whatever CA you want as the valid authority, using either the CApath or CAfile settings.

I've noticed that the default behavior for OpenSSL is to only verify certificates when it can build a complete chain, up to a self-signed root CA. Can this be overridden?

If the CA did not directly sign the end certificate, then yes, OpenSSL will only verify if it can build a chain. Without a chain, there is no provable connection, and no verification. I'm not sure what exactly you're suggesting when you say "Overridden".

I specifically do not want the root to be in the CAfile.

You're welcome to use CApath instead, but those are your only two options. It's kind of nonsensical to say "I want to specify the root, but specifically do not want to specify the root."

The fact that you specifically do not want to use CAfile to specify the CA means that either I don't understand what you're trying to do, or you don't understand what you're trying to do. Feel free to explain more about your scenario so we can help you better.

gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • Valid use case is that you trust the root CA, but not its other sub CAs. – Edheldil Dec 01 '16 at 16:56
  • and yet here i sit with a client demanding their crap to work again without giving me the root ca public key.. sometimes choice is limited. either i have to ditch security by disabling trust at all (customer would not care) or get it working with the intermediate ca that i obtained through openssl s_client. – GottZ May 27 '20 at 18:09