Cannot verify server's certificate when deploying to Azure Web App in ASE

We’re facing an issue with deploying to an Azure app within a App Service Environment (internal). This environment only has one app certificate valid for *.rootdomain.com.

When deploying an app with a Deploy To Azure step we’re getting the error: “…but could not verify the server’s certificate. If you trust the server, connect again and allow untrusted certificates”.

This indeed is correct because the Azure app certificates are not valid for *.scm.rootdomain.com.

Is there a way to add the attribute “–allowUntrusted” to the msdeploy call in this step?

Hello,

Thanks for getting in touch! We have found a work around from the Azure portal side, which is due to a bug in their SSL settings, have a look at this and see if it resolves the issue you’re experiencing: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ebd2bcf4-09ee-4b80-9492-82a465dbb345/incorrect-custom-certificate-on-mysitescmazurewebsitesnet?forum=windowsazurewebsitespreview Please let me know if it does or doesn’t work for you.

The missing allowUntrusted flag is a current limitation, it’s in our current queue of things to improve, I’ve lifted it up higher in the queue, but I don’t have an exact timeframe on when we’ll get to it.

You can follow along with it on GitHub here: https://github.com/OctopusDeploy/Issues/issues/3075

Regards,
Nick

Hi Nick,

Thanx for your reply. We’ve been further investigating as well and found the following solution.

We’re using an internal App Service Environment. This environment has its own custom domain and just one ip-address. You can only assings one certificate to this entire environment. This certificate is also used for the scm subdomain.

For an internal App Service Environment you should use a SSL certificate that covers the following domains (linkhttps://docs.microsoft.com/en-us/azure/app-service-web/app-service-app-service-environment-create-ilb-ase-resourcemanager):

  1. .com
  2. *..com
  3. *.scm..com

The App Service Certificates that can be ordered within the Azure Portal seem to lack the .scm. subdomain. So that causes this problem.

Possible solutions we’ve found:

  • ??Order a valid certificate with the 3 domains named from another certificate provider.
  • Use a self-signed certificate with these 3 domains, and add this certificate to the trusted certificate providers on your Octopus server. Beware a self-signed certificate might again cause problems using an upstream reverse-proxy / web application firewall.

Kind reagrds,

Marcel