configuring one-way tls from apigee edge to target server

[justlearning]

am trying to configure a one-way TLS from apigee edge (on-prem) to target server.

have tried the following:

1) created a TLS Keystores and uploaded a self-signed cert (.p12 format)

2) in the proxy target endpoint, set the following:

 <HTTPTargetConnection>
        <Properties/>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <KeyStore>ref://my-key-store</KeyStore>
            <KeyAlias>my-key-alias</KeyAlias>
        </SSLInfo>
        <URL>https://myendpoint.com/getData</URL>
</HTTPTargetConnection>

when I try to deploy the project, it says "revision is deployed, but traffic cannot flow."

Also, when I try to do a test connection from the keystores to the target hostname, it says "Invalid Truststore. Unable to find valid certification path to requested target"

any idea what went wrong?

[dchiesa1]

Yes

The documentation might be confusing on this, but, for connections from Apigee to an upstream system (aka northbound, aka backend, aka target)....

• If you are using 1-way TLS, then.... you need to specify a TrustStore in Apigee
• If you are using 2-way TLS, then you need to specify both a KeyStore and a TrustStore on the Apigee side.

It seems like you are specifying a KeyStore.  That's never sufficient. 

Let me try to explain the reason behind these KeyStore and TrustStore requirements in the case of 1-way or 2-way TLS. 

In TLS we speak of the two "peers" that engage in protected communication.  In the case of 1-way TLS, ONE of the peers authenticates the other peer. The first peer is often the client, or the initiating party.  The second peer is often the server, or the responding party. When you point your browser to your bank's website, it is probably engaging in a 1-way TLS handshake. The browser itself (Chrome or Microsoft Edge or Safari etc) will verify the identity of the remote bank webserver, in this way: in the process of the "TLS handshake" the browser asks the remote peer (the webserver) to present its certificate chain.  This is the chain of x509 certificates that the browser can use to verify the identity of the webserver.  The browser then looks at the chain, to see if the final certificate in the chain presented by the remote peer has been signed by a party that the browser trusts. The browser makes this decision by seeing if the final signing party has a certificate in the browser's own TRUSTSTORE.  If the TRUSTSTORE contains a root certificate that has signed the bottom cert in the chain returned by the peer, the browser says "OK I trust this site", and then completes the handshake, exchanges session keys, and then can engage in a secured transaction with encrypted communication. 

1-way TLS works exactly the same way when Apigee as as the client (or initiator), and in fact it works the same way for any TLS client.  Like curl, or a Java app that does TLS, or a C# app, or Powershell's Invoke-WebRequest.  They all work the same way.  The initiating peer must have a TRUSTSTORE to verify the responding party's chain of certificates.  In the case of a standard web browser, like Edge or Chome etc, the TRUSTSTORE is built-in, implicit, and automatic.  If you download and install Chrome, you get Chrome's truststore. (Though I think on MacOS, Chrome uses the system Truststore (cite)).  Likewise with curl; if you download and install that utility, you get curl's truststore.  And with Java, there is a builtin truststore in the Java runtime. 

Apigee is a little different in this regard. Apigee asks** that you EXPLICITLY provide the truststore you want to use to verify the peer's certificate chain.  That means you need to specify the Truststore, and load that truststore with at least one root certificate that Apigee should trust on your behalf.  (** "asks" is important here. If you DO NOT specify a Truststore, Apigee will supply one, that you do not control and cannot see or manage. For security conscious people, this is probably a bad idea, though people who value simplicity over control will be happy).   

On the other side, the responding peer (the bank website, or ... in your case the newrelic endpoint), must have a KEYSTORE.  This is the thing that holds the key, as well as the chain of certificates that have signed the key.  When a peer initiates a connection, the responding peer sends its certificate chain, pulled from the KEYSTORE. 

For 2-way TLS, both parties authenticate each other.  That means both parties need a TRUSTSTORE and a KEYSTORE.  The truststore is used to verify the other party.  The keystore is used to identify itself to the other party. 

so if you want 1-way TLS, in a communication initiated by Apigee (like ServiceCallout) specify a Truststore. 

If you want 2-way TLS in this case, specify both a TrustStore and a KeyStore.  

[samirj]

@dchiesa1 How does this apply if its Apigee X ? in terms of One and way 2 way TLS ? I read, I will have to use SSL cert at the Load Balancer level as the TLS terminates there. What about the TLS from Apigee X to Backend ?

[dchiesa1]

TLS from Apigee to the backend is the topic that I discussed in my earlier lengthy reply from 15 November 2021, the message in this threat that you replied to.  Read that. ^^