1-Way TLS Target Server Behaviour with CA Signed Cert + Truststore

With Apigee Edge, when configuring a Target Server that presents a CA signed cert, if you were to configure a Truststore with that cert, does that cause Apigee to locally validate the cert or would it still choose to validate via the CA.

Regardless, is it more correct to just allow Apigee to validate against the CA and omit the truststore?

Solved Solved
0 2 373
1 ACCEPTED SOLUTION

With Apigee Edge, when configuring a Target Server that presents a CA signed cert, if you were to configure a Truststore with that cert, does that cause Apigee to locally validate the cert or would it still choose to validate via the CA.

Apigee Edge performs TLS certificate validation according to the X.509 standard. All validation is "local". The way it works basically is:

  1. get the TLS certificate from the peer
  2. Verify that the Subject Name (SN) or Subject Alternative Name (SAN) matches the vhost. If not, reject.
  3. Verify the validity times (the not-before time, and the expiry time) on the cert. If "now" is not within the valid window, reject the certificate.
  4. Is the cert signed by a trusted CA (is the signing cert present in the truststore)?
    • YES --> accept the cert.
    • No --> Is the cert "self-signed" (aka a root CA)?
      • YES --> Reject the cert.
      • No --> Get the cert of the signer. Loop back to step 3.

All validation is local. There are no calls to external systems, including calls to any CA. This process is not unique to Apigee Edge. This is how TLS certificate validation works.

There are some elaborations, for example calling to a CA to check for a revocation list. Apigee Edge doesn't do this automatically with 1-way TLS from Apigee Edge to the target server.

What I described as an iterative loopback is sometimes called a "chain of trust" . You can read more about it in this StackExchange answer.

In your specific scenario, just adding the cert of the direct signing CA to the Apigee Edge truststore should guarantee that Apigee Edge will accept the cert. That is because Apigee Edge will follow the chain of trust when validating the peer certificate, and if the direct signing CA is trusted, then the chain of trust terminates and Apigee Edge is happy. Effectively by adding that cert to the Truststore you are establishing it as a "trust anchor".

I wrote an answer a while back that went into some additional detail on all of this.

View solution in original post

2 REPLIES 2

With Apigee Edge, when configuring a Target Server that presents a CA signed cert, if you were to configure a Truststore with that cert, does that cause Apigee to locally validate the cert or would it still choose to validate via the CA.

Apigee Edge performs TLS certificate validation according to the X.509 standard. All validation is "local". The way it works basically is:

  1. get the TLS certificate from the peer
  2. Verify that the Subject Name (SN) or Subject Alternative Name (SAN) matches the vhost. If not, reject.
  3. Verify the validity times (the not-before time, and the expiry time) on the cert. If "now" is not within the valid window, reject the certificate.
  4. Is the cert signed by a trusted CA (is the signing cert present in the truststore)?
    • YES --> accept the cert.
    • No --> Is the cert "self-signed" (aka a root CA)?
      • YES --> Reject the cert.
      • No --> Get the cert of the signer. Loop back to step 3.

All validation is local. There are no calls to external systems, including calls to any CA. This process is not unique to Apigee Edge. This is how TLS certificate validation works.

There are some elaborations, for example calling to a CA to check for a revocation list. Apigee Edge doesn't do this automatically with 1-way TLS from Apigee Edge to the target server.

What I described as an iterative loopback is sometimes called a "chain of trust" . You can read more about it in this StackExchange answer.

In your specific scenario, just adding the cert of the direct signing CA to the Apigee Edge truststore should guarantee that Apigee Edge will accept the cert. That is because Apigee Edge will follow the chain of trust when validating the peer certificate, and if the direct signing CA is trusted, then the chain of trust terminates and Apigee Edge is happy. Effectively by adding that cert to the Truststore you are establishing it as a "trust anchor".

I wrote an answer a while back that went into some additional detail on all of this.

Hi dchiesa1 ,

Thanks for your information, I see that you often provide high-quality answers in the community, so want to get your help. Here we want to record some TLS  information in the Traffic log in apigee, could  you help to advise? Thank you in advance:

I drew a simple flowchart, client (the user requesting the api deployed on apigee), apigee (forwarding the client's request to the virtual-host through nginx and then to the api provider), backend (configured in the target server's specific background service).

1. Regarding apigee, I know that apigee provides some flow variables, which allow us to easily get information such as TLS version and password and record them in Traffic Flow <MessageLogging>.
https://docs.apigee.com/api-platform/system-administration/tls-vars 


2. Regarding the client, when the client provides a TLS/SSL certificate, we can get client.cn client.organization.unit and tls.client.cert.fingerprint tls.client.raw.cert (the last two prefixes are tls. Maybe need to set <ClientProperties> to true). But I didn't find a certificate authority (CA), could you please advide? In addition, there also not found notBefore and notAfter, I tried to use $ssl_client_v_start; $ssl_client_v_end; from nginx and put them in the request header and then log them in Traffic Flow <MessageLogging>, I am not sure if this is the best practice, could you please advide? Thanks.
https://docs.apigee.com/api-platform/system-administration/tls-vars 
https://docs.apigee.com/api-platform/reference/variables-reference#client 

conf_load_balancing_load.balancing.driver.nginx.server.ssl.template.extra2=proxy_set_header...

3. Regarding the Target server, I know that we also have some flow variables, but I can't find the fingerprint, certificate authority (CA), notBefore and notAfter, etc. We hope to be able to record them in the Traffic log to realize before the certificate expires. 
https://docs.apigee.com/api-platform/reference/variables-reference#target 

James_wang_0-1686641548054.png