TLS Keystore / Truststore

cboyd
Participant II

Hi All,

When setting up the TLS keystore or truststore what kind or type of certificate do you use at the very bottom(?) of the chain, assuming the root CA is at the top?

Generally that would be a host or server certificate where the CSR would get generated. But since this is a cloud based system what should be used?

Thanks.

Solved Solved
0 2 1,145
1 ACCEPTED SOLUTION

In the truststore, you don't need to worry about ordering of certificates.

You mentioned a chain; and from your question it seems you are under the assumption that a chain of certificates must be loaded into the truststore in order to enable Apigee Edge to validate certificates.This isn't so.

Every cert you add to the trust store is a "trust anchor". That means it is implicitly trusted by the runtime.

Let's look at an example. Suppose you have a service that carries its own certificate. For our purposes, an x.509 certificate is just an association between a name (eg, www.upstream.com) and a public key (publickey1). This association gives peers (clients?) the confidence that if they encrypt a message using the public key from the certificate, then only the party known as "www.upstream.com" will be able to read the content, because only that party will know the private key necessary to decrypt the message. Basically the name+publickey pairing in the certificate gives peers a way to communicate securely with the owner of the cert.

How can a peer be certain that the name specified in the cert really belongs to the entity that we might informally associate with that name? What I mean is: I can claim to be Dino; how can you trust that I actually am Dino? In human interactions, we have physical documents that assert identities, like a driver's license or a passport. In the USA, the Driver's License asserts that the issuing state government thinks I am "Dino" (and can drive). My passport is an assertion by the US Government that I am a citizen of the USA. People who view these documents must trust the Government of the State of Washington, or the Federal Government of the USA, who are the respective issuing bodies of these documents, in order to trust the assertions in those documents.

In x.509, the certificate (and remember, the cert is an association between a public key and a name) is digitally signed by a certificate authority, or CA. Let's call the signing CA in this case "CA1". At this point, in order for a peer to trust that publickey1 belongs to the service reachable at www.upstream.com (in other words, to trust the cert), then the peer must trust CA1.

To allow people to evaluate the identity of the CA1, it also has a certificate, with a public key and a name. And that cert will also be signed, often by a different CA (maybe CA2). And this can continue, recursively. A certificate that is signed by itself is known as "self-signed" and is often treated as a root certificate.

As a result you have a sort of a chain of trust built on these signatures.

  • cert for www.upstream is signed by CA1
    • cert for CA1 is signed by CA2
      • cert for CA2 is signed by CA3
        • cert for CA3 is signed by CA3 (is self-signed)

When a peer (like Apigee Edge) evaluates trust of a certificate, it must do one of 3 things: trust the cert explicitly, trust the signer of the cert, or trust a signer somewhere further down the chain.

There are many many certificates, so to avoid the problem of trusting all of them independently, we usually rely on trusting certs that belong to signing CAs. A single CA could sign 1000 certs. If I trust the cert of the signing CA, then I can implicitly trust the 1000 other certs that it has signed.

But regarding trust of CA certs, let me restate something important. To trust a certificate, either we need to trust the direct signer, or any indirect signer.

x.509 does not require that a peer must explicitly trust ALL certificates in the chain in order to implicitly trust the top link in the chain. Nor does x.509 require that a peer explicitly trust only root certificates. Trusting any cert in the chain is enough to establish trust in the top link in the chain.

Let's look at a couple cases:

  1. you configure Apigee Edge with a Truststore TS1. You load exactly one cert into that truststore: the one for www.upstream.com. Apigee Edge will trust it.
  2. you load only the cert for CA1 into the truststore. Apigee Edge will trust the cert for www.upstream.com.
  3. You load only the cert for CA2 into the truststore. Apigee Edge will trust the cert for www.upstream.com .
  4. You load only the cert for CA3 into the truststore. Apigee Edge will trust the cert for www.upstream.com .

Including the cert for ANY direct or indirect signer means Apigee Edge will treat that signer's cert as a trust anchor, and will therefore be able to trust the cert for www.upstream.com . This is the case for any system that correctly implements the x.509 trust model.

How does this work in practice? The peer to Apigee Edge (www.upstream.com) , when contacted to perform a TLS handshake, will send down its certificate along with the related chain of certs. Apigee Edge just needs to check the validity of the chain (is it really a chain?) and then check if any of the certs in the chain are trusted. If that's so, then Apigee Edge will trust the cert for www.upstream.com.

This works IF THE SERVICE IS CONFIGURED PROPERLY. If the service at www.upstream.com is configured incorrectly it may deliver only a single cert, rather than the full chain. This is a common configuration error (Example). In that case, Apigee Edge cannot magically establish the chain, and so cannot evaluate trust "down the chain". Which means only in the 1st case above will Apigee Edge trust the cert for www.upstream.com. I hope you see why. (Maybe the 2nd case, too, but I'm not certain about that. In any case the right thing to do is to fix the service to deliver the full chain during handshake).

OK, so to answer your question about the order of certs...

When setting up the TLS keystore or truststore what kind or type of certificate do you use at the very bottom(?)

The question should be moot; you shouldn't need to load an entire chain into the trust store. Usually you need only the root cert. If in practice this is not correct, then you may have a misconfigured upstream. Use openssl to evaluate whether the upstream is correctly sending a chain of certs during TLS negotiation.

There is no "bottom" in the truststore. It's just a unordered set of certs designated as trust anchors. Each one is a "bottom". The set of certs need not be related, and usually isn't. There is a "bottom" or "end" to a chain of certs, but you don't need multiple links of any chain in your truststore, unless your service is misconfigured.

View solution in original post

2 REPLIES 2

In the truststore, you don't need to worry about ordering of certificates.

You mentioned a chain; and from your question it seems you are under the assumption that a chain of certificates must be loaded into the truststore in order to enable Apigee Edge to validate certificates.This isn't so.

Every cert you add to the trust store is a "trust anchor". That means it is implicitly trusted by the runtime.

Let's look at an example. Suppose you have a service that carries its own certificate. For our purposes, an x.509 certificate is just an association between a name (eg, www.upstream.com) and a public key (publickey1). This association gives peers (clients?) the confidence that if they encrypt a message using the public key from the certificate, then only the party known as "www.upstream.com" will be able to read the content, because only that party will know the private key necessary to decrypt the message. Basically the name+publickey pairing in the certificate gives peers a way to communicate securely with the owner of the cert.

How can a peer be certain that the name specified in the cert really belongs to the entity that we might informally associate with that name? What I mean is: I can claim to be Dino; how can you trust that I actually am Dino? In human interactions, we have physical documents that assert identities, like a driver's license or a passport. In the USA, the Driver's License asserts that the issuing state government thinks I am "Dino" (and can drive). My passport is an assertion by the US Government that I am a citizen of the USA. People who view these documents must trust the Government of the State of Washington, or the Federal Government of the USA, who are the respective issuing bodies of these documents, in order to trust the assertions in those documents.

In x.509, the certificate (and remember, the cert is an association between a public key and a name) is digitally signed by a certificate authority, or CA. Let's call the signing CA in this case "CA1". At this point, in order for a peer to trust that publickey1 belongs to the service reachable at www.upstream.com (in other words, to trust the cert), then the peer must trust CA1.

To allow people to evaluate the identity of the CA1, it also has a certificate, with a public key and a name. And that cert will also be signed, often by a different CA (maybe CA2). And this can continue, recursively. A certificate that is signed by itself is known as "self-signed" and is often treated as a root certificate.

As a result you have a sort of a chain of trust built on these signatures.

  • cert for www.upstream is signed by CA1
    • cert for CA1 is signed by CA2
      • cert for CA2 is signed by CA3
        • cert for CA3 is signed by CA3 (is self-signed)

When a peer (like Apigee Edge) evaluates trust of a certificate, it must do one of 3 things: trust the cert explicitly, trust the signer of the cert, or trust a signer somewhere further down the chain.

There are many many certificates, so to avoid the problem of trusting all of them independently, we usually rely on trusting certs that belong to signing CAs. A single CA could sign 1000 certs. If I trust the cert of the signing CA, then I can implicitly trust the 1000 other certs that it has signed.

But regarding trust of CA certs, let me restate something important. To trust a certificate, either we need to trust the direct signer, or any indirect signer.

x.509 does not require that a peer must explicitly trust ALL certificates in the chain in order to implicitly trust the top link in the chain. Nor does x.509 require that a peer explicitly trust only root certificates. Trusting any cert in the chain is enough to establish trust in the top link in the chain.

Let's look at a couple cases:

  1. you configure Apigee Edge with a Truststore TS1. You load exactly one cert into that truststore: the one for www.upstream.com. Apigee Edge will trust it.
  2. you load only the cert for CA1 into the truststore. Apigee Edge will trust the cert for www.upstream.com.
  3. You load only the cert for CA2 into the truststore. Apigee Edge will trust the cert for www.upstream.com .
  4. You load only the cert for CA3 into the truststore. Apigee Edge will trust the cert for www.upstream.com .

Including the cert for ANY direct or indirect signer means Apigee Edge will treat that signer's cert as a trust anchor, and will therefore be able to trust the cert for www.upstream.com . This is the case for any system that correctly implements the x.509 trust model.

How does this work in practice? The peer to Apigee Edge (www.upstream.com) , when contacted to perform a TLS handshake, will send down its certificate along with the related chain of certs. Apigee Edge just needs to check the validity of the chain (is it really a chain?) and then check if any of the certs in the chain are trusted. If that's so, then Apigee Edge will trust the cert for www.upstream.com.

This works IF THE SERVICE IS CONFIGURED PROPERLY. If the service at www.upstream.com is configured incorrectly it may deliver only a single cert, rather than the full chain. This is a common configuration error (Example). In that case, Apigee Edge cannot magically establish the chain, and so cannot evaluate trust "down the chain". Which means only in the 1st case above will Apigee Edge trust the cert for www.upstream.com. I hope you see why. (Maybe the 2nd case, too, but I'm not certain about that. In any case the right thing to do is to fix the service to deliver the full chain during handshake).

OK, so to answer your question about the order of certs...

When setting up the TLS keystore or truststore what kind or type of certificate do you use at the very bottom(?)

The question should be moot; you shouldn't need to load an entire chain into the trust store. Usually you need only the root cert. If in practice this is not correct, then you may have a misconfigured upstream. Use openssl to evaluate whether the upstream is correctly sending a chain of certs during TLS negotiation.

There is no "bottom" in the truststore. It's just a unordered set of certs designated as trust anchors. Each one is a "bottom". The set of certs need not be related, and usually isn't. There is a "bottom" or "end" to a chain of certs, but you don't need multiple links of any chain in your truststore, unless your service is misconfigured.

Thanks @Dino-at-Google. This does indeed help me better understand things in Apigee.

I very much appreciate the detailed answer!