Welcome back. In this lesson we discuss adding mutual TLS support for your API deployments in the API gateway service. First, a quick review in mutual TLS authentication, sometimes referred to as two-way SSL both the client and server in this case, your gateway, authenticate each other by providing their digital certificates so that both parties are assured of the other's identity. In this aspect, there are handshake messages used to establish the encrypted channel prior to actually exchanging data. The client initiates the handshake by sending a hello message to the server. The message will include which TLS version and cipher suites they support, along with some other information. In reply to the client, the gateway sends a message containing the gateway server certificate, the chosen cipher suite, and some other encryption information, along with a request for the client to send their certificate. The client invalidates the gateway certificate using one of the certificate authorities contained in their trust door then they send their certificate to the gateway server along with the session key information that is encrypted with the server's public key. Now, API gateway will validate the client's TLS certificate to verify the client's identity using one of the custom certificate authorities in its trust store. Then, finally it sends a finished message, completing the handshake. At this point, the API request and response can be processed securely on the encrypted channel. How is this configured in API gateway? Well, you simply add a request policy in the API deployment specification to add mutual TLS support to an API. The mTLS requests policy applies globally to all routes in that API deployment specification. Now, for extra control, you can also specify that certificates presented must contain particular values in the certificates email address, URL, or domain name fields. In that case, the gateway will reject requests from clients certificates that do not contain them. If you don't specify values for these fields, API gateway will accept all requests as long as the certificate is valid. Also be aware that in a mutual TLS handshake, the API gateway only uses custom certificate authorities and custom CA bundles to verify client certificates. Before you click to enable mTLS as an API requests policy, you must first add the custom CA or CA bundle to your gateways trust store. We will discuss more on that topic in another lesson. Let's now take a quick peek as to how this is done in the OCI console. Let's navigate to developer services, API management, and gateways. Here I already have a gateway created that we can use for this demo and one of the requirements before I edit a deployment policy is to make sure that I have one or more custom certificate authorities or a CA bundle and as you can see here, I indeed do. This will work. Let's go over to our deployments. I have a deployment that I created earlier, which is a simple doorway into a demo function that can be called and we're going to update its configuration to add that mutual TLS requests policy. It's as simple as clicking enable and then if I left it there, then it would accept all certificates from anyone as long as it's valid but we could limit this to one or more domains. In this case, I'm going to add example.com and maybe example2.com. I could add another one, maybe it's example.org, depending on what the use case is. You can actually add up to 10 of these if you need too. From there, I simply click on ''Next'' and next, since I've already configured the configuration, I can show those filters that I've set for this and then save those changes. This will then update the API deployment in this gateway and that completes the demo. That's it for this lesson on adding mutual TLS support for API deployments. Thanks for watching.
