#appservice

Cloud Native & SQL database service for Tours & Travels company

The following is a list of ports used by an App Service Environment:

Inbound security rules

454: Required port used by Azure infrastructure for managing and maintaining App Service Environments. Do not block traffic to this port.

455: Required port used by Azure infrastructure for managing and maintaining App Service Environments. Do not block traffic to this port.

80: Default port for inbound HTTP traffic to apps running in App Service Plans in an App Service Environment

443: Default port for inbound SSL traffic to apps running in App Service Plans in an App Service Environment

21: Control channel for FTP. This port can be safely blocked if FTP is not being used.

10001-10020: Data channels for FTP. As with the control channel, these ports can be safely blocked if FTP is not being used

4016: Used for remote debugging with Visual Studio 2012. This port can be safely blocked if the feature is not being used.

4018: Used for remote debugging with Visual Studio 2013. This port can be safely blocked if the feature is not being used.

4020: Used for remote debugging with Visual Studio 2015. This port can be safely blocked if the feature is not being used.

Outbound security rules

Outbound network connectivity to Azure Storage endpoints worldwide. This includes endpoints located in the same region as the App Service Environment, as well as storage endpoints located in other Azure regions. Azure Storage endpoints resolve under the following DNS domains: table.core.windows.net, blob.core.windows.net, queue.core.windows.net and file.core.windows.net.

Outbound network connectivity to Sql DB endpoints located in the same region as the App Service Environment. SQl DB endpoints resolve under the following domain: database.windows.net.

Outbound network connectivity to the Azure management plane endpoints (both ASM and ARM endpoints). This includes outbound connectivity to both management.core.windows.net and management.azure.com.

Outbound network connectivity to ocsp.msocsp.com. This is needed to support SSL functionality.

The DNS configuration for the virtual network must be capable of resolving all of the endpoints and domains mentioned in the earlier points. If these endpoints cannot be resolved, App Service Environment creation attempts will fail, and existing App Service Environments will be marked as unhealthy.

If a custom DNS server exists on the other end of a VPN gateway, the DNS server must be reachable from the subnet containing the App Service Environment.

The outbound network path cannot travel through internal corporate proxies, nor can it be force tunneled to on-premises. Doing so changes the effective NAT address of outbound network traffic from the App Service Environment. Changing the NAT address of an App Service Environment's outbound network traffic will cause connectivity failures to many of the endpoints listed above. This results in failed App Service Environment creation attempts, as well as previously healthy App Service Environments being marked as unhealthy.

Design great UI for mobile apps with corner solutions. App design is the look and feel of a mobile application.

For More Details:-

Phone No :+91 8856864638

Email: [email protected]

TL;DR: If you receive “Bad Request (51008): The parameter certificateEnvelope.Properties.KeyVaultId has an invalid value.” as part of your App Service deployment when using an SSL cert hosted in Azure Key Vault you have probably tried changing what Key Vault to use which does not seem to be supported. The workaround is to manually remove any usage of the certificate and also the certificate itself and then to redeploy your infrastructure.

The longer story

I just recently blogged about how to solve an issue with Azure Key Vault when the certificate was in the wrong format. Another issue I found when I was exploring the combination of Azure App Service and Azure Key Vault for SSL certificates was that I was unable to change what Key Vault to use.

In my ARM template I had simply changed what keyVaultId to use for Microsoft.Web/certificates, but that seems to be read only once set.

The ARM definition would look something like this:

{ "type": "Microsoft.Web/certificates", "name": "peterorneholm", "apiVersion": "2016-03-01", "location": "westeurope", "properties": { "keyVaultId": "/subscriptions/b2d60a3f-bef4-441c-88de-0c6831390c8d/resourceGroups/peterorneholm/providers/Microsoft.KeyVault/vaults/peterorneholm", "keyVaultSecretName": "mycert" } },

And changing the keyVaultId would result in the following error:

Resource Microsoft.Web/certificates 'peterorneholm' failed with message '{ "Code": "BadRequest", "Message": "The parameter certificateEnvelope.Properties.KeyVaultId has an invalid value.", "Target": null, "Details": [ { "Message": "The parameter certificateEnvelope.Properties.KeyVaultId has an invalid value." }, { "Code": "BadRequest" }, { "ErrorEntity": { "Code": "BadRequest", "Message": "The parameter certificateEnvelope.Properties.KeyVaultId has an invalid value.", "ExtendedCode": "51008", "MessageTemplate": "The parameter {0} has an invalid value.", "Parameters": [ "certificateEnvelope.Properties.KeyVaultId" ], "InnerErrors": null } } ], "Innererror": null }'

The workaround I came up with was to manually delete any hostname bindings using the certificate and finally delete the certificate resource itself (the one in Azure App Service). This could be accomplished with the APIs (through Poweshell for example), but in my case I found it simpler to just use the resource explorer available at http://resources.azure.com/.