3

Free managed app service cert creation/generation failing with below CNAME error:

Error:Failed to create App Service Managed Certificate for hostname Subdomain.rootdomain.com. Click here for more details. Error Details: Properties.CanonicalName is invalid. Current CNAME records of the hostname are Subdomain.someotherdomain.com,subdomain.trafficmanager.net,subdomain.azurewebsites.net

I was able to repro and make it work if my CName mapping is via subdomain to my default *.azurewebsites.net.

However, the issue seems to be appearing when my CName points to another subdomain before the default *.azurewebsites.net as seen in error message below:

enter image description here

Any insights on this issue is appreciated?

Niha
  • 294
  • 3
  • 7

1 Answers1

4

You are seeing this behavior as it’s not a supported feature in Azure App Services yet. While generating managed free certificated azure will run certain checks on domain and looks for a valid CName ie, either pointed to “.azurewebsites.net” or “.trafficmanager.net” In order to solve this problem please follow below steps in order:

  • Remove Cname Subdomain.someotherdomain.com (sub.devopsauthor.com), make sure there is only one Cname which is pointed to either “.azurewebsites.net” or “.trafficmanager.net”

  • Now attempt to generate the Certificate and bind it to domain.

  • If you still want the Subdomain.someotherdomain.com after cert generation, you can readd the Cname.

Naga sandeep
  • 102
  • 1
  • 1
  • 8
  • Are there any plans to support it? Always pointing to “.azurewebsites.net” or “.trafficmanager.net” only, without intermediate hosts seems unnecessarily restrictive. – Alexander Feb 16 '21 at 17:53
  • @naga-sandeep - I'm getting a similar error and I'm confused by the answer above. If I remove www.mydomain.com from the cname records for mydomain.com, people won't be able to find www.mydomain.com, right? Are you suggesting that I can remove it very breifly to creat the cert and immediatly re-instate it? That seems pretty iffy - I guess I could reduce the TTL to something smaller. Is there a more robust way to manage this? Maybe I could move to an ALIAS record and map www.mydomain.com directly that way? – David W Gray Sep 19 '21 at 01:10
  • @DavidWGray Hi David, sorry to see that you are facing an error. Please remove all other Cname records in App Service and then make sure only one Cname record is present in the DNS with .azurewebsites.net and then generate the cert. You can validate DNS record names on https://www.digwebinterface.com/. Kindly make sure .azurewebsites.net Cname is present in the list. If you want a custom answer for your domain, Please kindly share your sub domain name (which you want to get a free managed cert). I can provide a more suitable answer for your scinario. – Naga sandeep Sep 20 '21 at 02:43
  • @naga-sandeep - Thanks. The domain is music4dance.net - mapped to music4dance.azurewebsites.net. Currently, I have an external cert that covers the root URL and the www subdomain and uses IP binding. I would love to move to the free certs (and happy to move to SNI binding as well) but I'm definitely getting confused. I was able to create a cert for www.music4dance.net once I set up a cname record directly from www to music4dance.azurewebsites.net and I could also create a cert for the root. But I don't think I can apply separate IP bound certs since it's the same IP? – David W Gray Sep 21 '21 at 04:13
  • For what its' worth, I used SNI based binding to separately bind each of the certificates that were autogenerated to the root domain and the www subdomain. I can see the www certificate in my browser (since I autoredirect to www from the root, I couldn't verify that through the browser). But this tool https://ssltools.godaddy.com/views/certChecker is telling me that both are working. I still feel like I don't quite understand what's going on, but I'm glad it's functional. Thanks for your help! – David W Gray Sep 22 '21 at 03:03