How SSL pinning can be done in APIGEE X for Northb...

Madhavikrishna

I have a requirement for establishing ssl pinning for northbound connections. @dchiesa1 Can you please suggest here.

dchiesa1

I guess you're talking about one of these:

pinning a token to a particular TLS session (the one that initiated the token)
pinning a client ID to a particular TLS client-side cert

In either case, you need to propagate the TLS information from the client to the Apigee proxy. If using Edge, use PropagateTLSInformation, it's a property on the vhost. If using X, then you need to configure the external load balancer to propagate the information. see here.

For the first, case - pinning a token - use OAuthV2/GenerateAccessToken as you normally would. This will validate the client credentials. Use a custom attribute in the policy to attach the Subject DN (or fingerprint, or whatever... the distinguishing thing from the client cert) to the token. Upon token validation, you first do OAuthV2/VerifyAccessToken, and then subsequently, you check the retrieved custom attribute against the value (fingerprint, Subject DN, or etc) for the "current" client certificate. If the values are the same, OK. If not, reject.

For the latter, again you need to you would need to attach the client-side cert distinguishing value (fingerprint, subject DN, etc), as a custom attribute on the registered client entity in Apigee. Then, upon request-for-token, you first must VerifyAPIKey on the client (or GetOAuthV2Info), to retrieve that custom attribute, and compare the value retrieved, with the value propagated by the load balancer (for X) or by the virtual host (for Edge). Reject if the values don't match. If they do match, you can issue the token.

You could combine these mechanisms. In other words you could do both. I haven't thought about the utility of doing that. I guess it depends on how leak-prone you think the OAuth tokens are.

dchiesa1

BWTW, this sample shows you how to set up mTLS on the "northbound", ingress side of Apigee X.

https://github.com/GoogleCloudPlatform/apigee-samples/tree/main/mtls-northbound

It doesn't get into pinning, but it does go into specific details regarding how you can get the fingerprint, serial number, subject DN, etc, into HTTP headers. On Apigee X, that's a pre-requisite to the pinning stuff.

Madhavikrishna

@dchiesa1 thank you for suggestion. Can you please clarify below queries also. I would like to implement mTLS for northbound connections.

1.Lenient enforcement happens in the API proxy flow. In this case, the proxy must use Conditions on the custom header values and a RaiseFault policy to reject the request.

Will this says Client certificate validation will happen at API(not at GLB) and that would not impact all other API proxies.Correct?Or it will require validation with all other API proxies available over APIGEE?

2.Why we need private CA?
Apigee will have its certificate,key in keystore. Client will use this certficate for secure handshake.

3.Setup using CloudShell
Can't we do it using management console?

dchiesa1

1.Lenient enforcement happens in the API proxy flow. In this case, the proxy must use Conditions on the custom header values and a RaiseFault policy to reject the request.

Will this says Client certificate validation will happen at API(not at GLB) and that would not impact all other API proxies.Correct?Or it will require validation with all other API proxies available over APIGEE?

The load balancer can enforce mTLS. What you and I are talking about , I think , is the proxy pinning a token to a TLS cert. It is one thing to say "ok, this client is communicating using a trusted cert". That's what the LB does when it enforces mTLS. It is another thing to crack open the request, examine the token, determine what cert was used to obtain the token, and then compare THAT value to the the cert that is being used in the current request. That part is the pinning part, and that is somehting you cannot do in the LB. You must do that in something like Apigee.

Client cert validation - the standard mTLS handshake - happens at the LB. That will impact anything behind the LB. What Apigee does is check the cert to see that it is the same one used for a prior transaction - the request-for-token transaction.

2.Why we need private CA?
Apigee will have its certificate,key in keystore. Client will use this certficate for secure handshake.

You do not need a private CA. That article discussed a private CA, but there's no need for you to use a private CA. You can use your own CA. You should refer to the documentation on mTLS configuration for the load balancer, which is here: https://cloud.google.com/load-balancing/docs/mtls

It says that you can use Certs provided by a third party CA of your choice, certs provided by a private CA, and self-signed certs.

3.Setup using CloudShell
Can't we do it using management console?

I don't know - are you referring to the article regarding mTLS setup? It's possible the management console UX is not quite ready. As I understand the mTLS capability on the LB has been added relatively recently. I suggest you cross-check the information in the tutorial, with the doc for mTLS. https://cloud.google.com/load-balancing/docs/mtls

Madhavikrishna

@dchiesa1 Thank you for response.

How SSL pinning can be done in APIGEE X for Northbound connections?