TLS/SSL - Simplifying all possible ways to enable TLS on API Proxies

After going through lot of documentation, i am bit confused and hence I am putting up my understanding for review:

1. To enable Backend TLS/SSL security: HTTP Proxy to HTTPS backend

- Create a Truststore in Edge.

- Add a PEM cert to this Truststore, get this cert from backend team.

- Create a Truststore Reference.

- Add this Reference in SSLInfo tag of /target/default.xml and deploy the bundle.

2. To enable one way TLS/SSL security on Proxy : HTTPS Proxy to HTTPS backend.

- Create one Truststores in Edge - backAndFrontStore

- Add a backend PEM cert with appropriate alias and front-end cert with appropriate alias to backAndFrontStore.

- Create Truststore reference pointing to backAndFrontStore.

- Add this Reference in SSLInfo tag of /target/default.xml and deploy the bundle.


3. To enable 2-way TLS/SSL security on Proxy: HTTPS Proxy with client cert validation to HTTPS backend.

- Create one Truststores in Edge - backAndFrontStore

- Add a backend PEM cert with appropriate alias and front-end cert with appropriate alias to backAndFrontStore.

- Create Truststore reference pointing to backAndFrontStore.

- Create on keystore in Edge - clientKeystore.

- Add PKCS12 cert to clientKeystore.

- Create Keystore reference pointing to clientKeystore.

- Add both of these references to SSLInfo tag along with ClientAuth as Enabled and deploy the bundle.

Also, if we have a simple org where all Proxies can have same client cert, then only adding Ref to Virtual Host is more appropriate? Or is there any other tight dependency on Virtual Host for adding the reference of Stores there?

0 1 251
1 REPLY 1

I think a diagram might help. I don't understand the distinction between your case 1 and case 2.

BTW, You used the term HTTP Proxy and HTTPS proxy, and maybe by that you are implying that the API proxy in Apigee listens on HTTP (insecure port 80). And that's an error. Don't do that. Yes, it's permitted by Apigee, but it's a bad idea. Just like leaving your car doors unlocked when you park at the mall. You could do it, but you shouldn't do it.

Here's the way I think about it. There are two connections. inbound (w.r.t. Apigee) and outbound.

You can have 1-way or 2-way TLS on either or both. You should not use insecure (port 80) connections on either.

Regardless of whether you are considering inbound or outbound...

In the case of 1-way TLS

  • the receiving end needs a keystore, configured appropriately with the privatekey identifying the endpoint and a cert that binds the publickey to the endpoint name (DNS name).
  • the sending end needs a truststore, configured with the cert of the signing CA for the cert presented by the receiver peer. (It's a little more complicated than that because of signing chains, but this is the general idea)

In the case of 2-way TLS, it's reflexive! Both ends need a keystore and truststore! And they should be configured just as described above.

*NB: the terms "keystore" and "truststore" may not be universal among all TLS-enabled systems. But generally these terms are used, and in the case in which they are not used, you should be able to figure out the analogous terms. For example, here's the KB article for F5 Big-IP, which talks about configuring certs and keys. F5 uses the term "Client SSL Profile", which is analogous to a TRUSTSTORE in Apigee and other systems, and for KEYSTORE they use the term "SSL Certificate List".