Guide

TLS and mTLS support

This chapter describes how TLS termination and mutual TLS (mTLS) are supported in the App & API Protector Hybrid reverse proxy deployment.

Traffic flows:

  • Inbound traffic. It refers to traffic that flows from the client through the network load balancer to the reverse proxy (Client → Network Load Balancer → Reverse Proxy).
  • Outbound traffic. It refers to traffic that flows from the reverse proxy VM through the application load balancer to the origin application (Reverse Proxy → Application Load Balancer → Origin Application).

The reverse proxy can terminate inbound TLS sessions, including mutual TLS (mTLS), and can also establish TLS or mTLS sessions with the origin application. The behavior depends on how certificates and termination are configured.

TLS termination at Network Load Balancer

If TLS termination is configured at the internet-facing Network Load Balancer, the reverse proxy receives only HTTP traffic. In this case:

  • The reverse proxy treats TLS termination as disabled.
  • No certificate expiry date can be displayed in the reverse proxy Connection Configuration, since the TLS termination occurs outside of the reverse proxy.

TLS termination at reverse proxy

When TLS termination is enabled at the reverse proxy, it is the reverse proxy that handles inbound TLS connections directly from clients. The following cases describe how the reverse proxy can process inbound and outbound traffic:

  • Case 1. Client (TLS) → Reverse Proxy → Origin Application (non-TLS)
    • Inbound traffic. The TLS connection from the client terminates at the reverse proxy. The reverse proxy handles the inbound TLS handshake and decrypts the traffic before processing the request.
    • Outbound traffic. After decrypting the client request, the reverse proxy forwards it to the origin application over clear-text HTTP. No TLS encryption is applied on the connection between the reverse proxy and the origin application.
    • Certificates at the reverse proxy. The reverse proxy uses a server certificate and private key provided by you to complete the TLS handshake with the client. This certificate identifies the application domain and establishes a secure channel for inbound traffic.

This mode is typically used when the origin is in a private, secured network, and the performance or inspection requirements justify removing TLS on the backend.

  • Case 2. Client (TLS) → Reverse Proxy → Origin Application (TLS)
    • Inbound traffic. The TLS connection from the client terminates at the reverse proxy. The reverse proxy performs the inbound TLS handshake, decrypts the request, and processes it according to the configured routing or inspection rules.
    • Outbound traffic. After processing the client request, the reverse proxy establishes a new TLS connection to the origin application. The request is re-encrypted before being sent to the backend, maintaining end-to-end encryption between the client and the origin.
    • Certificates at the reverse proxy:
      • The reverse proxy uses a server certificate and a private key provided by you to complete the TLS handshake with the client.
      • For outbound connections, reverse proxy uses a trusted CA certificate to validate the origin application’s server certificate during the TLS handshake.

  • Case 3. Client (mTLS) → Reverse Proxy → Origin Application (mTLS)
    • Inbound traffic. The mTLS connection from the client terminates at the reverse proxy. During the inbound mTLS handshake, both the client and the reverse proxy authenticate each other using their respective certificates. The reverse proxy validates the client’s certificate before accepting the connection and decrypting the request.
    • Outbound traffic. After processing the inbound request, the reverse proxy establishes a new mTLS connection to the origin application. During this handshake, both sides authenticate using certificates. The reverse proxy validates the origin application’s server certificate and presents its own client certificate to complete the authentication process.
    • Certificates at the reverse proxy:
      • The reverse proxy uses a server certificate and a private key to complete the inbound mTLS handshake with the client. It also uses a trusted CA certificate to validate the client’s certificate during inbound authentication.
      • For outbound connections, the reverse proxy uses a trusted CA certificate to validate the origin server’s certificate and a client certificate to authenticate itself to the origin during the outbound mTLS handshake.

  • Case 4: Client (mTLS) → Reverse Proxy → Origin Application (TLS)
    • Inbound traffic. The mTLS connection from the client terminates at the reverse proxy. During this process, the reverse proxy presents the server certificate and server key to establish a secure channel with the client. The reverse proxy also uses a CA certificate to validate the client certificate received as part of the inbound mTLS handshake. This ensures that only trusted clients can establish connections.
    • Outbound traffic. TLS connection is established to the origin application. For outbound connections, the reverse proxy initiates a standard TLS session with the origin application. In this scenario, the reverse proxy acts as the client. It validates the server certificate presented by the origin application using the configured CA certificate. This ensures that traffic between the reverse proxy and the origin application remains encrypted and trusted.
    • Certificates at the reverse proxy. The reverse proxy requires the following certificates and keys:
      • Server certificate and a private key. Used to terminate inbound TLS or mTLS connections.
      • CA certificate that validates:
        • Client certificate received during inbound mTLS handshake.
        • Server certificate presented by the origin application during outbound TLS handshake.

Certificate management and monitoring

The reverse proxy Connection Configuration only renders certificate status for certificates uploaded or pushed to the reverse proxy:

  • Server certificate (inbound traffic)
  • Client certificate (outbound traffic)

It does not contain CA certificates used to validate inbound client certificates or outbound server certificates. When certificates are signed by a public CA, inbound mTLS validation does not require an uploaded CA certificate as the chain is already trusted. Also, for enterprise TLS deployments, you must upload the enterprise CA certificate to the reverse proxy for outbound validation. However, the validity of enterprise CAs is managed and monitored independently by yourself.

TLS termination status

The reverse proxy Connection Configuration reflects TLS termination as follows:

  • TLS termination disabled.
    • Applies when termination occurs at the external Network Load Balancer.
    • Reverse proxy receives HTTP traffic only.
    • No certificate expiry date is displayed.
  • TLS termination enabled.
    • Applies when termination occurs at the reverse proxy.
    • Reverse proxy displays the server certificate expiry date.

Reverse proxy's role in outbound communication

The reverse proxy is designed to manage inbound traffic to backend services in a sandwich deployment model (between the Network Load Balancer and the Application Load Balancer). In this model:

  • Reverse proxy acts as a server for inbound connections from clients.
  • Reverse proxy also acts as a client when establishing outbound TLS or mTLS connections to the origin application.
  • For general outbound requests from enterprise systems (for example, accessing the internet), traffic does not pass through the reverse proxy. Instead, outbound traffic typically flows through a forward proxy or an internet gateway (for example, AWS Internet Gateway).

Updated 1 day ago