Merge pull request #110438 from TimShererWithAquent/us1679050dq

Change SSL to TLS per 1679050 (2 of 2)

Author: v-shils

articles/application-gateway/create-url-route-portal.md

@@ -203,4 +203,4 @@ Review the settings on the **Review + create** tab, and then select **Create** t
 
 ## Next steps
 
-- [Enabling end to end SSL on Azure Application Gateway](application-gateway-backend-ssl.md)
+- [Enabling end to end TLS on Azure Application Gateway](application-gateway-backend-ssl.md)

articles/application-gateway/key-vault-certs.md

@@ -1,5 +1,5 @@
 ---
-title: SSL termination with Azure Key Vault certificates
+title: TLS termination with Azure Key Vault certificates
 description: Learn how you can integrate Azure Application Gateway with Key Vault for server certificates that are attached to HTTPS-enabled listeners.
 services: application-gateway
 author: vhorne
@@ -9,25 +9,25 @@ ms.date: 4/25/2019
 ms.author: victorh
 ---
 
-# SSL termination with Key Vault certificates
+# TLS termination with Key Vault certificates
 
-[Azure Key Vault](../key-vault/key-vault-overview.md) is a platform-managed secret store that you can use to safeguard secrets, keys, and SSL certificates. Azure Application Gateway supports integration with Key Vault for server certificates that are attached to HTTPS-enabled listeners. This support is limited to the v2 SKU of Application Gateway.
+[Azure Key Vault](../key-vault/key-vault-overview.md) is a platform-managed secret store that you can use to safeguard secrets, keys, and TLS/SSL certificates. Azure Application Gateway supports integration with Key Vault for server certificates that are attached to HTTPS-enabled listeners. This support is limited to the v2 SKU of Application Gateway.
 
-Key Vault integration offers two models for SSL termination:
+Key Vault integration offers two models for TLS termination:
 
-- You can explicitly provide SSL certificates attached to the listener. This model is the traditional way to pass SSL certificates to Application Gateway for SSL termination.
+- You can explicitly provide TLS/SSL certificates attached to the listener. This model is the traditional way to pass TLS/SSL certificates to Application Gateway for TLS termination.
 - You can optionally provide a reference to an existing Key Vault certificate or secret when you create an HTTPS-enabled listener.
 
 Application Gateway integration with Key Vault offers many benefits, including:
 
-- Stronger security, because SSL certificates aren't directly handled by the application development team. Integration allows a separate security team to:
+- Stronger security, because TLS/SSL certificates aren't directly handled by the application development team. Integration allows a separate security team to:
   * Set up application gateways.
   * Control application gateway lifecycles.
   * Grant permissions to selected application gateways to access certificates that are stored in your key vault.
 - Support for importing existing certificates into your key vault. Or use Key Vault APIs to create and manage new certificates with any of the trusted Key Vault partners.
 - Support for automatic renewal of certificates that are stored in your key vault.
 
-Application Gateway currently supports software-validated certificates only. Hardware security module (HSM)-validated certificates are not supported. After Application Gateway is configured to use Key Vault certificates, its instances retrieve the certificate from Key Vault and install them locally for SSL termination. The instances also poll Key Vault at 24-hour intervals to retrieve a renewed version of the certificate, if it exists. If an updated certificate is found, the SSL certificate currently associated with the HTTPS listener is automatically rotated.
+Application Gateway currently supports software-validated certificates only. Hardware security module (HSM)-validated certificates are not supported. After Application Gateway is configured to use Key Vault certificates, its instances retrieve the certificate from Key Vault and install them locally for TLS termination. The instances also poll Key Vault at 24-hour intervals to retrieve a renewed version of the certificate, if it exists. If an updated certificate is found, the TLS/SSL certificate currently associated with the HTTPS listener is automatically rotated.
 
 > [!NOTE]
 > The Azure portal only supports KeyVault Certificates, not secrets. Application Gateway still supports referencing secrets from KeyVault, but only through non-Portal resources like PowerShell, CLI, API, ARM templates, etc. 
@@ -46,10 +46,10 @@ Application Gateway integration with Key Vault requires a three-step configurati
 
 1. **Configure the application gateway**
 
-   After you complete the two preceding steps, you can set up or modify an existing application gateway to use the user-assigned managed identity. You can also configure the HTTP listener’s SSL certificate to point to the complete URI of the Key Vault certificate or secret ID.
+   After you complete the two preceding steps, you can set up or modify an existing application gateway to use the user-assigned managed identity. You can also configure the HTTP listener’s TLS/SSL certificate to point to the complete URI of the Key Vault certificate or secret ID.
 
    ![Key vault certificates](media/key-vault-certs/ag-kv.png)
 
 ## Next steps
 
-[Configure SSL termination with Key Vault certificates by using Azure PowerShell](configure-keyvault-ps.md)
+[Configure TLS termination with Key Vault certificates by using Azure PowerShell](configure-keyvault-ps.md)

articles/application-gateway/migrate-v1-v2.md

@@ -31,7 +31,7 @@ An Azure PowerShell script is available that does the following:
 
 * The new v2 gateway has new public and private IP addresses. It isn't possible to move the IP addresses associated with the existing v1 gateway seamlessly to v2. However, you can allocate an existing (unallocated) public or private IP address to the new v2 gateway.
 * You must provide an IP address space for another subnet within your virtual network where your v1 gateway is located. The script can't create the v2 gateway in any existing subnets that already have a v1 gateway. However, if the existing subnet already has a v2 gateway, that may still work provided there's enough IP address space.
-* To  migrate an SSL configuration, you must specify all the SSL certs used in your v1 gateway.
+* To  migrate a TLS/SSL configuration, you must specify all the TLS/SSL certs used in your v1 gateway.
 * If you have FIPS mode enabled for your V1 gateway, it won't be migrated to your new v2 gateway. FIPS mode isn't supported in v2.
 * v2 doesn't support IPv6, so IPv6 enabled v1 gateways aren't migrated. If you run the script, it may not complete.
 * If the v1 gateway has only a private IP address, the script creates a public IP address and a private IP address for the new v2 gateway. v2 gateways currently don't support only private IP addresses.
@@ -96,7 +96,7 @@ To run the script:
 
    * **subnetAddressRange: [String]:  Required** - This is the IP address space that you've allocated (or want to allocate) for a new subnet that contains your new v2 gateway. This must be specified in the CIDR notation. For example: 10.0.0.0/24. You don't need to create this subnet in advance. The script creates it for you if it doesn't exist.
    * **appgwName: [String]: Optional**. This is a string you specify to use as the name for the new Standard_v2 or WAF_v2 gateway. If this parameter isn't supplied, the name of your existing v1 gateway will be used with the suffix *_v2* appended.
-   * **sslCertificates: [PSApplicationGatewaySslCertificate]: Optional**.  A comma-separated list of PSApplicationGatewaySslCertificate objects that you create to represent the SSL certs from your v1 gateway must be uploaded to the new v2 gateway. For each of your SSL certs configured for your Standard v1 or WAF v1 gateway, you can create a new PSApplicationGatewaySslCertificate object via the `New-AzApplicationGatewaySslCertificate` command shown here. You need the path to your SSL Cert file and the password.
+   * **sslCertificates: [PSApplicationGatewaySslCertificate]: Optional**.  A comma-separated list of PSApplicationGatewaySslCertificate objects that you create to represent the TLS/SSL certs from your v1 gateway must be uploaded to the new v2 gateway. For each of your TLS/SSL certs configured for your Standard v1 or WAF v1 gateway, you can create a new PSApplicationGatewaySslCertificate object via the `New-AzApplicationGatewaySslCertificate` command shown here. You need the path to your TLS/SSL Cert file and the password.
 
      This parameter is only optional if you don't have HTTPS listeners configured for your v1 gateway or WAF. If you have at least one HTTPS listener setup, you must specify this parameter.
 

articles/application-gateway/redirect-http-to-https-cli.md

@@ -1,7 +1,7 @@
 ---
 title: HTTP to HTTPS redirection using CLI
 titleSuffix: Azure Application Gateway
-description: Learn how to create an application gateway and add a certificate for SSL termination using the Azure CLI.
+description: Learn how to create an application gateway and add a certificate for TLS termination using the Azure CLI.
 services: application-gateway
 author: vhorne
 ms.service: application-gateway
@@ -12,7 +12,7 @@ ms.author: victorh
 
 # Create an application gateway with HTTP to HTTPS redirection using the Azure CLI
 
-You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances.
+You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for TLS/SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances.
 
 In this article, you learn how to:
 

articles/application-gateway/redirect-http-to-https-portal.md

@@ -11,7 +11,7 @@ ms.author: victorh
 ---
 # Create an application gateway with HTTP to HTTPS redirection using the Azure portal
 
-You can use the Azure portal to create an [application gateway](overview.md) with a certificate for SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances.
+You can use the Azure portal to create an [application gateway](overview.md) with a certificate for TLS termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances.
 
 In this article, you learn how to:
 

articles/application-gateway/redirect-http-to-https-powershell.md

@@ -11,7 +11,7 @@ ms.author: victorh
 
 # Create an application gateway with HTTP to HTTPS redirection using Azure PowerShell
 
-You can use the Azure PowerShell to create an [application gateway](overview.md) with a certificate for SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances. 
+You can use the Azure PowerShell to create an [application gateway](overview.md) with a certificate for TLS/SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) for the backend pool of the application gateway that contains two virtual machine instances. 
 
 In this article, you learn how to:
 

articles/application-gateway/renew-certificates.md

@@ -12,7 +12,7 @@ ms.author: victorh
 
 # Renew Application Gateway certificates
 
-At some point, you'll need to renew your certificates if you configured your application gateway for SSL encryption.
+At some point, you'll need to renew your certificates if you configured your application gateway for TLS/SSL encryption.
 
 You can renew a certificate associated with a listener using either the Azure portal, Azure PowerShell, or Azure CLI:
 
@@ -58,4 +58,4 @@ az network application-gateway ssl-cert update \
 
 ## Next steps
 
-To learn how to configure SSL Offloading with Azure Application Gateway, see [Configure SSL Offload](application-gateway-ssl-portal.md)
+To learn how to configure TLS Offloading with Azure Application Gateway, see [Configure TLS Offload](application-gateway-ssl-portal.md)

articles/application-gateway/self-signed-certificates.md

@@ -12,9 +12,9 @@ ms.author: victorh
 
 # Generate an Azure Application Gateway self-signed certificate with a custom root CA
 
-The Application Gateway v2 SKU introduces the use of Trusted Root Certificates to allow backend servers. This removes authentication certificates that were required in the v1 SKU. The *root certificate* is a Base-64 encoded X.509(.CER) format root certificate from the backend certificate server. It identifies the root certificate authority (CA) that issued the server certificate and the server certificate is then used for the SSL communication.
+The Application Gateway v2 SKU introduces the use of Trusted Root Certificates to allow backend servers. This removes authentication certificates that were required in the v1 SKU. The *root certificate* is a Base-64 encoded X.509(.CER) format root certificate from the backend certificate server. It identifies the root certificate authority (CA) that issued the server certificate and the server certificate is then used for the TLS/SSL communication.
 
-Application Gateway trusts your website's certificate by default if it's signed by a well-known CA (for example, GoDaddy or DigiCert). You don't need to explicitly upload the root certificate in that case. For more information, see [Overview of SSL termination and end to end SSL with Application Gateway](ssl-overview.md). However, if you have a dev/test environment and don't want to purchase a verified CA signed certificate, you can create your own custom CA and create a self-signed certificate with it. 
+Application Gateway trusts your website's certificate by default if it's signed by a well-known CA (for example, GoDaddy or DigiCert). You don't need to explicitly upload the root certificate in that case. For more information, see [Overview of TLS termination and end to end TLS with Application Gateway](ssl-overview.md). However, if you have a dev/test environment and don't want to purchase a verified CA signed certificate, you can create your own custom CA and create a self-signed certificate with it. 
 
 > [!NOTE]
 > Self-signed certificates are not trusted by default and they can be difficult to maintain. Also, they may use outdated hash and cipher suites that may not be strong. For better security, purchase a certificate signed by a well-known certificate authority.
@@ -120,15 +120,15 @@ The CSR is a public key that is given to a CA when requesting a certificate. The
    - fabrikam.crt
    - fabrikam.key
 
-## Configure the certificate in your web server's SSL settings
+## Configure the certificate in your web server's TLS settings
 
-In your web server, configure SSL using the fabrikam.crt and fabrikam.key files. If your web server can't take two files, you can combine them to a single .pem or .pfx file using OpenSSL commands.
+In your web server, configure TLS using the fabrikam.crt and fabrikam.key files. If your web server can't take two files, you can combine them to a single .pem or .pfx file using OpenSSL commands.
 
 ### IIS
 
 For instructions on how to import certificate and upload them as server certificate on IIS, see [HOW TO: Install Imported Certificates on a Web Server in Windows Server 2003](https://support.microsoft.com/help/816794/how-to-install-imported-certificates-on-a-web-server-in-windows-server).
 
-For SSL binding instructions, see [How to Set Up SSL on IIS 7](https://docs.microsoft.com/iis/manage/configuring-security/how-to-set-up-ssl-on-iis#create-an-ssl-binding-1).
+For TLS binding instructions, see [How to Set Up SSL on IIS 7](https://docs.microsoft.com/iis/manage/configuring-security/how-to-set-up-ssl-on-iis#create-an-ssl-binding-1).
 
 ### Apache
 
@@ -146,9 +146,9 @@ The following configuration is an example [virtual host configured for SSL](http
 
 ### NGINX
 
-The following configuration is an example [NGINX server block](https://nginx.org/docs/http/configuring_https_servers.html) with SSL configuration:
+The following configuration is an example [NGINX server block](https://nginx.org/docs/http/configuring_https_servers.html) with TLS configuration:
 
-![NGINX with SSL](media/self-signed-certificates/nginx-ssl.png)
+![NGINX with TLS](media/self-signed-certificates/nginx-ssl.png)
 
 ## Access the server to verify the configuration
 
@@ -227,7 +227,7 @@ $probe = Get-AzApplicationGatewayProbeConfig `
 
 ## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
 ## to the domain name of the server certificate as this will be set as the SNI header and
-## will be used to verify the backend server's certificate. Note that SSL handshake will
+## will be used to verify the backend server's certificate. Note that TLS handshake will
 ## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes
 
 Add-AzApplicationGatewayBackendHttpSettings `
@@ -267,5 +267,5 @@ Set-AzApplicationGateway -ApplicationGateway $gw
 
 ## Next steps
 
-To learn more about SSL\TLS in Application Gateway, see [Overview of SSL termination and end to end SSL with Application Gateway](ssl-overview.md).
+To learn more about SSL\TLS in Application Gateway, see [Overview of TLS termination and end to end TLS with Application Gateway](ssl-overview.md).
 

articles/application-gateway/tutorial-ssl-cli.md

@@ -1,6 +1,6 @@
 ---
-title: SSL termination using CLI - Azure Application Gateway
-description: Learn how to create an application gateway and add a certificate for SSL termination using the Azure CLI.
+title: TLS termination using CLI - Azure Application Gateway
+description: Learn how to create an application gateway and add a certificate for TLS termination using the Azure CLI.
 services: application-gateway
 author: vhorne
 ms.service: application-gateway
@@ -10,9 +10,9 @@ ms.author: victorh
 ms.custom: mvc
 ---
 
-# Create an application gateway with SSL termination using the Azure CLI
+# Create an application gateway with TLS termination using the Azure CLI
 
-You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for [SSL termination](ssl-overview.md). For backend servers, you can use a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) . In this example, the scale set contains two virtual machine instances that are added to the default backend pool of the application gateway.
+You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for [TLS termination](ssl-overview.md). For backend servers, you can use a [virtual machine scale set](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md) . In this example, the scale set contains two virtual machine instances that are added to the default backend pool of the application gateway.
 
 In this article, you learn how to: