Skip to content

Commit d674854

Browse files
authored
Merge pull request #268238 from MicrosoftDocs/repo_sync_working_branch
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
2 parents b864baa + 9ae380b commit d674854

17 files changed

+69
-44
lines changed

articles/app-service/environment/app-service-app-service-environment-create-ilb-ase-resourcemanager.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@ Most of the parameters in the *azuredeploy.parameters.json* file are common to c
3535
* *3* means both HTTP/HTTPS traffic on ports 80/443, and the control/data channel ports listened to by the FTP service on the ASE, will be bound to an ILB allocated virtual network internal address.
3636
* *2* means only the FTP service related ports (both control and data channels) will be bound to an ILB address, while the HTTP/HTTPS traffic will remain on the public VIP.
3737
* *0* means all traffic is bound to the public VIP making the ASE external.
38-
* *dnsSuffix*: This parameter defines the default root domain that will be assigned to the ASE. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. However since an ILB ASE is internal to a customer's virtual network, it doesn't make sense to use the public service's default root domain. Instead, an ILB ASE should have a default root domain that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of *internal-contoso.com* for apps that are intended to only be resolvable and accessible within Contoso's virtual network.
38+
* *dnsSuffix*: This parameter defines the default root domain that will be assigned to the ASE. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. However since an ILB ASE is internal to a customer's virtual network, it doesn't make sense to use the public service's default root domain. Instead, an ILB ASE should have a default root domain that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of *internal.contoso.com* for apps that are intended to only be resolvable and accessible within Contoso's virtual network.
3939
* *ipSslAddressCount*: This parameter is automatically defaulted to a value of 0 in the *azuredeploy.json* file because ILB ASEs only have a single ILB address. There are no explicit IP-SSL addresses for an ILB ASE, and so the IP-SSL address pool for an ILB ASE must be set to zero, otherwise a provisioning error will occur.
4040

4141
Once the *azuredeploy.parameters.json* file has been filled in for an ILB ASE, the ILB ASE can then be created using the following PowerShell code snippet. Change the file paths to match where the Azure Resource Manager template files are located on your machine. Also remember to supply your own values for the Azure Resource Manager deployment name, and resource group name.
@@ -50,7 +50,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
5050
After the Azure Resource Manager template is submitted, it will take a few hours for the ILB ASE to be created. Once the creation completes, the ILB ASE will show up in the portal UX in the list of App Service Environments for the subscription that triggered the deployment.
5151

5252
## Uploading and Configuring the "Default" TLS/SSL Certificate
53-
Once the ILB ASE is created, a TLS/SSL certificate should be associated with the ASE as the "default" TLS/SSL certificate use for establishing TLS/SSL connections to apps. Continuing with the hypothetical Contoso Corporation example, if the ASE's default DNS suffix is *internal-contoso.com*, then a connection to *`https://some-random-app.internal-contoso.com`* requires a TLS/SSL certificate that is valid for **.internal-contoso.com*.
53+
Once the ILB ASE is created, a TLS/SSL certificate should be associated with the ASE as the "default" TLS/SSL certificate use for establishing TLS/SSL connections to apps. Continuing with the hypothetical Contoso Corporation example, if the ASE's default DNS suffix is *internal.contoso.com*, then a connection to *`https://some-random-app.internal.contoso.com`* requires a TLS/SSL certificate that is valid for **.internal.contoso.com*.
5454

5555
There are different ways to obtain a valid TLS/SSL certificate including internal CAs, purchasing a certificate from an external issuer, and using a self-signed certificate. Regardless of the source of the TLS/SSL certificate, the following certificate attributes need to be configured properly:
5656

@@ -64,7 +64,7 @@ Then the resultant .pfx file needs to be converted into a base64 string because
6464
The PowerShell code snippet below shows an example of generating a self-signed certificate, exporting the certificate as a .pfx file, converting the .pfx file into a base64 encoded string, and then saving the base64 encoded string to a separate file. The PowerShell code for base64 encoding was adapted from the [PowerShell Scripts Blog][examplebase64encoding].
6565

6666
```azurepowershell-interactive
67-
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal-contoso.com","*.scm.internal-contoso.com"
67+
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
6868
6969
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
7070
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
@@ -128,7 +128,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
128128

129129
After the Azure Resource Manager template is submitted, it will take roughly 40 minutes per ASE front-end to apply the change. For example, with a default sized ASE using two front-ends, the template will take around 1 hour and 20 minutes to complete. While the template is running the ASE will not be able to scaled.
130130

131-
Once the template completes, apps on the ILB ASE can be accessed over HTTPS and the connections will be secured using the default TLS/SSL certificate. The default TLS/SSL certificate will be used when apps on the ILB ASE are addressed using a combination of the application name plus the default hostname. For example, *`https://mycustomapp.internal-contoso.com`* would use the default TLS/SSL certificate for **.internal-contoso.com*.
131+
Once the template completes, apps on the ILB ASE can be accessed over HTTPS and the connections will be secured using the default TLS/SSL certificate. The default TLS/SSL certificate will be used when apps on the ILB ASE are addressed using a combination of the application name plus the default hostname. For example, *`https://mycustomapp.internal.contoso.com`* would use the default TLS/SSL certificate for **.internal.contoso.com*.
132132

133133
However, just like apps running on the public multi-tenant service, developers can also configure custom host names for individual apps, and then configure unique SNI TLS/SSL certificate bindings for individual apps.
134134

articles/app-service/environment/certificates.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ You cannot create the ASE and upload the certificate as one action in the portal
4141
If you want to create a self signed certificate quickly for testing, you can use the following bit of PowerShell:
4242

4343
```azurepowershell-interactive
44-
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal-contoso.com","*.scm.internal-contoso.com"
44+
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
4545
4646
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
4747
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
@@ -89,7 +89,7 @@ dir cert:\localmachine\root
8989
To perform testing, you can create a self signed certificate and generate a *.cer* file with the following PowerShell:
9090

9191
```azurepowershell-interactive
92-
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal-contoso.com","*.scm.internal-contoso.com"
92+
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
9393
9494
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
9595
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

articles/app-service/environment/create-from-template.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -32,11 +32,11 @@ When you create an ASE from a template, you must start with:
3232
* The subscription you want to deploy into.
3333
* The location you want to deploy into.
3434

35-
To automate your ASE creation, follow they guidelines in the following sections. If you're creating an ILB ASEv2 with custom dnsSuffix (for example, `internal-contoso.com`), there are a few more things to do.
35+
To automate your ASE creation, follow they guidelines in the following sections. If you're creating an ILB ASEv2 with custom dnsSuffix (for example, `internal.contoso.com`), there are a few more things to do.
3636

3737
1. After your ILB ASE with custom dnsSuffix is created, an TLS/SSL certificate that matches your ILB ASE domain should be uploaded.
3838

39-
2. The uploaded TLS/SSL certificate is assigned to the ILB ASE as its "default" TLS/SSL certificate. This certificate is used for TLS/SSL traffic to apps on the ILB ASE when they use the common root domain that's assigned to the ASE (for example, `https://someapp.internal-contoso.com`).
39+
2. The uploaded TLS/SSL certificate is assigned to the ILB ASE as its "default" TLS/SSL certificate. This certificate is used for TLS/SSL traffic to apps on the ILB ASE when they use the common root domain that's assigned to the ASE (for example, `https://someapp.internal.contoso.com`).
4040

4141

4242
## Create the ASE
@@ -51,7 +51,7 @@ If you want to make an ASE, use this Resource Manager template [ASEv2][quickstar
5151
* *existingVirtualNetworkResourceGroup*: his parameter defines the resource group name of the existing virtual network and subnet where ASE will reside.
5252
* *subnetName*: This parameter defines the subnet name of the existing virtual network and subnet where ASE will reside.
5353
* *internalLoadBalancingMode*: In most cases, set this to 3, which means both HTTP/HTTPS traffic on ports 80/443, and the control/data channel ports listened to by the FTP service on the ASE, will be bound to an ILB-allocated virtual network internal address. If this property is set to 2, only the FTP service-related ports (both control and data channels) are bound to an ILB address. If this property is set to 0, the HTTP/HTTPS traffic remains on the public VIP.
54-
* *dnsSuffix*: This parameter defines the default root domain that's assigned to the ASE. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. Because an ILB ASE is internal to a customer's virtual network, it doesn't make sense to use the public service's default root domain. Instead, an ILB ASE should have a default root domain that makes sense for use within a company's internal virtual network. For example, Contoso Corporation might use a default root domain of *internal-contoso.com* for apps that are intended to be resolvable and accessible only within Contoso's virtual network. To specify custom root domain you need to use api version `2018-11-01` or earlier versions.
54+
* *dnsSuffix*: This parameter defines the default root domain that's assigned to the ASE. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. Because an ILB ASE is internal to a customer's virtual network, it doesn't make sense to use the public service's default root domain. Instead, an ILB ASE should have a default root domain that makes sense for use within a company's internal virtual network. For example, Contoso Corporation might use a default root domain of *internal.contoso.com* for apps that are intended to be resolvable and accessible only within Contoso's virtual network. To specify custom root domain you need to use api version `2018-11-01` or earlier versions.
5555
* *ipSslAddressCount*: This parameter automatically defaults to a value of 0 in the *azuredeploy.json* file because ILB ASEs only have a single ILB address. There are no explicit IP-SSL addresses for an ILB ASE. Hence, the IP-SSL address pool for an ILB ASE must be set to zero. Otherwise, a provisioning error occurs.
5656

5757
After the *azuredeploy.parameters.json* file is filled in, create the ASE by using the PowerShell code snippet. Change the file paths to match the Resource Manager template-file locations on your machine. Remember to supply your own values for the Resource Manager deployment name and the resource group name:
@@ -66,7 +66,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
6666
It takes about two hours for the ASE to be created. Then the ASE shows up in the portal in the list of ASEs for the subscription that triggered the deployment.
6767

6868
## Upload and configure the "default" TLS/SSL certificate
69-
A TLS/SSL certificate must be associated with the ASE as the "default" TLS/SSL certificate that's used to establish TLS connections to apps. If the ASE's default DNS suffix is *internal-contoso.com*, a connection to `https://some-random-app.internal-contoso.com` requires an TLS/SSL certificate that's valid for **.internal-contoso.com*.
69+
A TLS/SSL certificate must be associated with the ASE as the "default" TLS/SSL certificate that's used to establish TLS connections to apps. If the ASE's default DNS suffix is *internal.contoso.com*, a connection to `https://some-random-app.internal.contoso.com` requires an TLS/SSL certificate that's valid for **.internal.contoso.com*.
7070

7171
Obtain a valid TLS/SSL certificate by using internal certificate authorities, purchasing a certificate from an external issuer, or using a self-signed certificate. Regardless of the source of the TLS/SSL certificate, the following certificate attributes must be configured properly:
7272

@@ -87,7 +87,7 @@ Use the following PowerShell code snippet to:
8787
This PowerShell code for base64 encoding was adapted from the [PowerShell scripts blog][examplebase64encoding]:
8888

8989
```powershell
90-
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal-contoso.com","*.scm.internal-contoso.com"
90+
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
9191
9292
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
9393
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
@@ -151,7 +151,7 @@ New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-
151151

152152
It takes roughly 40 minutes per ASE front end to apply the change. For example, for a default-sized ASE that uses two front ends, the template takes around 1 hour and 20 minutes to complete. While the template is running, the ASE can't scale.
153153

154-
After the template finishes, apps on the ILB ASE can be accessed over HTTPS. The connections are secured by using the default TLS/SSL certificate. The default TLS/SSL certificate is used when apps on the ILB ASE are addressed by using a combination of the application name plus the default host name. For example, `https://mycustomapp.internal-contoso.com` uses the default TLS/SSL certificate for **.internal-contoso.com*.
154+
After the template finishes, apps on the ILB ASE can be accessed over HTTPS. The connections are secured by using the default TLS/SSL certificate. The default TLS/SSL certificate is used when apps on the ILB ASE are addressed by using a combination of the application name plus the default host name. For example, `https://mycustomapp.internal.contoso.com` uses the default TLS/SSL certificate for **.internal.contoso.com*.
155155

156156
However, just like apps that run on the public multitenant service, developers can configure custom host names for individual apps. They also can configure unique SNI TLS/SSL certificate bindings for individual apps.
157157

articles/app-service/environment/how-to-custom-domain-suffix.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ If you don't have an App Service Environment, see [How to Create an App Service
1919
> This article covers the features, benefits, and use cases of App Service Environment v3, which is used with App Service Isolated v2 plans.
2020
>
2121
22-
The custom domain suffix defines a root domain that can be used by the App Service Environment. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. For ILB App Service Environments, the default root domain is *appserviceenvironment.net*. However, since an ILB App Service Environment is internal to a customer's virtual network, customers can use a root domain in addition to the default one that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of *internal-contoso.com* for apps that are intended to only be resolvable and accessible within Contoso's virtual network. An app in this virtual network could be reached by accessing *APP-NAME.internal-contoso.com*.
22+
The custom domain suffix defines a root domain that can be used by the App Service Environment. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. For ILB App Service Environments, the default root domain is *appserviceenvironment.net*. However, since an ILB App Service Environment is internal to a customer's virtual network, customers can use a root domain in addition to the default one that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of *internal.contoso.com* for apps that are intended to only be resolvable and accessible within Contoso's virtual network. An app in this virtual network could be reached by accessing *APP-NAME.internal.contoso.com*.
2323

2424
The custom domain suffix is for the App Service Environment. This feature is different from a custom domain binding on an App Service. For more information on custom domain bindings, see [Map an existing custom DNS name to Azure App Service](../app-service-web-tutorial-custom-domain.md).
2525

@@ -63,7 +63,7 @@ The certificate for custom domain suffix must be stored in an Azure Key Vault. T
6363

6464
:::image type="content" source="./media/custom-domain-suffix/key-vault-networking.png" alt-text="Screenshot of a sample networking page for key vault to allow custom domain suffix feature.":::
6565

66-
Your certificate must be a wildcard certificate for the selected custom domain name. For example, *internal-contoso.com* would need a certificate covering **.internal-contoso.com*. If the certificate used by the custom domain suffix contains a Subject Alternate Name (SAN) entry for scm, for example **.scm.internal-contoso.com*, the scm site will also available using the custom domain suffix.
66+
Your certificate must be a wildcard certificate for the selected custom domain name. For example, *internal.contoso.com* would need a certificate covering **.internal.contoso.com*. If the certificate used by the custom domain suffix contains a Subject Alternate Name (SAN) entry for scm, for example **.scm.internal.contoso.com*, the scm site will also available using the custom domain suffix.
6767

6868
If you rotate your certificate in Azure Key Vault, the App Service Environment will pick up the change within 24 hours.
6969

@@ -170,7 +170,7 @@ If you want to use your own DNS server, add the following records:
170170

171171
To configure DNS in Azure DNS private zones:
172172

173-
1. Create an Azure DNS private zone named for your custom domain. In the example below, the custom domain is *internal-contoso.com*.
173+
1. Create an Azure DNS private zone named for your custom domain. In the example below, the custom domain is *internal.contoso.com*.
174174
1. Create an A record in that zone that points * to the inbound IP address used by your App Service Environment.
175175
1. Create an A record in that zone that points @ to the inbound IP address used by your App Service Environment.
176176
:::image type="content" source="./media/custom-domain-suffix/custom-domain-suffix-dns-configuration.png" alt-text="Screenshot of a sample DNS configuration for your custom domain suffix.":::

0 commit comments

Comments
 (0)