You plan to configure an Azure Application Gateway v2 to support end-to-end TLS encryption. The backend pool contains web servers that use a self-signed TLS certificate.
You need to configure the Application Gateway to ensure that all traffic from clients to the backend servers is encrypted using TLS.
Which five actions should you perform in sequence? To answer, arrange the actions in the correct order.
- 1Export the public key of the self-signed certificate from the backend servers as a .cer file.
- 2Upload the exported .cer certificate to the Application Gateway to create a trusted root certificate.
- 3Create HTTPS backend settings and select the uploaded trusted root certificate.
- 4Create an HTTPS listener, upload the frontend certificate (.pfx file), and bind it to port 443.
- 5Create a request routing rule that links the HTTPS listener, the backend pool, and the HTTPS backend settings.
Answer
The correct sequence of steps starts with exporting the public key certificate (.cer) from the backend servers, uploading it to the Application Gateway to establish a trusted root certificate, configuring HTTPS backend settings with that certificate, creating an HTTPS listener with a frontend certificate (.pfx), and finally linking these components with a request routing rule.
To configure end-to-end TLS on Azure Application Gateway v2 with self-signed backend certificates, you must first export the backend public key (.cer) and upload it to the gateway as a trusted root certificate. This allows you to configure HTTPS backend settings. You then configure the frontend listener using an HTTPS listener with a private key certificate (.pfx) to decrypt client traffic. Finally, you bind these together using a request routing rule.
Step-by-Step Solution
Key Concept
Azure Application Gateway v2 requires both a frontend TLS certificate (.pfx) for the listener and a backend trusted root certificate (.cer) for the backend settings to achieve end-to-end TLS encryption with self-signed backend certificates.