Azure doesn't use the right certificate - azure

I have build a new webapp on Azure. So i followed that steps:
Add A Record (A/#/52.173.76.33), a CNAME (CNAME/www/saschamannsde.azurewebsites.net) and a TXT (TXT/#/saschamannsde.azurewebsites.net)
Added a custom domain to the webapp (Then it is listed as available host)
Upload the PFX and CER and bind it to my domain.
Azure now shows me, that it is a valid Certificate with my hostname saschamanns.de and issued by Sectigo RSA Domain Validation Secure Server CA (ID 134d36755287a5e0718554ff9c9103d13f331d34).
If i now typing https://saschamanns.de the browser tells me, i have a false cert, issued for shortener.secureserver.net.
Inside the Supportpage of Azure it tells me two problems:
Certificate mismatch detected (
The hostname saschamanns.de is configured to a Certificate with the thumbprint 134d36755287a5e0718554ff9c9103d13f331d34 on this Azure web app. However, the site returned a certificate with thumbprint 22873d8fefeb318394d1b906a5e4657876552d80.) A traceroute gives me:
https://paste.ubuntu.com/p/5427RCBmMF/
And it looks like it routes to the MS Routes.
DNS resolution error detected (As per the current DNS settings, URL saschamanns.de resolves to 184.168.131.241. The web app on Azure however is configured to listen on 52.173.76.33.)
But i have already set the IP to 52.173.76.33. The other IP comes from my Domain Manager GoDaddy.
Maybe anyone can help to identify the problem?

From the Dig web interface , saschamanns.de is also pointing to 184.168.131.241 . What is this 184.168.131.241 ip ?
saschamanns.de. 599 IN A 184.168.131.241
saschamanns.de. 599 IN A 52.173.76.33
If you browse the web app , certificate ( Thumbprint : 22873d8fefeb318394d1b906a5e4657876552d80) showing in browser is issued to shortener.secureserver.net .
Certificate which is binded to web app is not issued to saschamanns.de
Can you try bind the certificate again to web app by removing the existing one. Hopefully that should resolve the issue.

I also just ran into the same issue. Basically, the reason why I got the certificate mismatch error was according to the Forwarding Feature of GoDaddy.
If you use the forwarding feature - it will add a locked "A record" entry to the domain pointing to ip.secureserver.net which in my case was 184.168.131.241.
However tanner west explains the forwarding issue in a gist article.
In a nutshell, don´t use the forwarding feature and edit the DNS forwarding manually.
This is the feature I am talking about.

Related

How to resolve OnPrem REST API - DNS Name from Azure API

Environment- Established the connection between Azure App Service and OnPrem Network and vrified the connection.
Requirement - There is API hosted in OnPrem and with DNS name and HTTPS enabled (https://test.com/GetData)
But OnPrem API cannot be accessible from Azure API using DNS name and getting error like Hostname cannot be found.
But When I mention the Onprem API IP address (https://12.34.34.3/GetData), it seems communication established but ssl error - The SSL connection could not be established.
What would be the best solution here.
Regards
Abdul
Reason for "Hostname not found error" is the custom domain is not mapped to the Azure App service properly.
Please go to "Custom Domains" and check if the custom domain is added or not.
If not added, please follow the below procedure to add custom domain :
please click on "+ Add Custom Domain"
enter the domain and click on validate.
Add CNAME and TXT records in your DNS domain to verify domain ownership.
Click on "Add Custom Domain"
After adding the custom domain, the custom domain is still unsecure. You need to add the SSL certificate.
To add SSL certificate, please follow below procedure :
Go to TLS / SSL settings and click on "+ Add TLS / SSL Binding"
Select your custom domain and import the .pfx or public certificate for you domain and click Add.
Go to Custom Domains section and click on "Add binding".
Select the certificate of your domain and TLS/SSL type as SNI.
Click on "Add binding"
Now, you can access API using your custom domain which is secured.
When an app hosted on Azure App Service and tries to connect to a remote endpoint over SSL, it is important that the certificate on the remote endpoint service is issued by a Trusted Root CA. If the certificate on the remote service is a self-signed certificate or a private CA certificate, it will not be trusted by the instance hosting your app and the SSL handshake will fail with this error.
Possible solutions are:
1: Remote endpoint service must use a certificate issued by Trusted Root CA.
2: Host the application on App Service Environment (ASE) where you can upload your internal CA root certificate and use WEBSITE_LOAD_ROOT_CERTIFICATES appsetting to load it into Trusted Root store.

Failed to create Free App Service Managed Cert

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:
Any insights on this issue is appreciated?
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.

Transfer Godaddy Domain to Azure App Service

I have a domain in Godaddy called "x.app" and I want to transfer it to Azure App Service. I have created a DNS Zone called "x.app" and I changed all the Nameservers in Godaddy:
In Azure DNS Zone, I have created a CNAME, A, TXT Records:
A has name of # and value of App Service IP Address
CNAME has name of wildcard * and alias of App Service domain
TXT has name of # and value of App Service domain
I have added the Name of x.app as a custom domain and added a keyvault certificate:
When I just browse my domain: x.app I receive this error:
Your connection is not private Attackers might be trying to steal your
information from x.app (for example, passwords, messages, or credit
cards).
Anybody has an idea, what could cause this problem? Thank you!
There might be a typo. According to your DNS records configuration in Azure DNS, you should add the domain x.app instead of x.com as the custom domain in the app service.
If you have done it. These errors typically originate from two things: the first is a client-side issue (your browser, computer, OS), and the second is that there is an actual problem with the certificate on the website (expired, wrong domain, not trusted by the organization). You could get more tips to fix the error here.
For the error, you could also check an error code message which helps to try and pinpoint the exact issue and click the Advanced in Google Chrome. For example,
NET::ERR_CERT_COMMON_NAME_INVALID (this occurs when the certificate
does not match the domain)
In this case, you could upload an SSL certificate in which CN or DNS name matches the domain x.app. Additionally, when you bind a certificate with IP SSL, App Service creates a new, dedicated IP address for your app. You should remap A record for IP SSL with this dedicated IP address.

Bluemix scalable container group custom domain SSL certificate

Ok, I have finally managed to get my node.js container up and running using a scalable container group and a custom domain.
The problem that now remains is: How do you get the self-signed certificate to be used by Bluemix when accessing the app through https://my-app.mydomain.com?
Https works, but it shows the wildcard *.mybluemix.net certificate instead of the one I added to the domain that I added to my organisation. Visiting https://my-app.mybluemix.net is ok since then the wildcard mybluemix.net certificate is valid.
Yes, I have seen this one as well as read the SSL part of the Bluemix docs.
developerWorks: SSL Certificates and Bluemix Custom Domains
Your DNS should use an A record pointing to 75.126.81.68. This IP address is used by Bluemix for SSL traffic in the US-South region.
If you are using an A record with 75.126.81.66 or use a CNAME record pointing to your app's route (e.g. my-app.mybluemix.net), then you will see the *.mybluemix.net certificate instead of your custom certificate that you uploaded to Bluemix and associated to your custom domain.

Wrong SSL certificate is returned for an Azure website

We have two websites in Azure under different subscriptions which use the same UCC SSL certificate. Everything had been good for a long time until a week or two ago we noticed that one of the sites does not really have our certificate (although it was configured in Azure successfully). When browsing to it using "https" we can see that "https" becomes red, and if we click on it it says: "Server's certificate does not match the URL". The detailed information about the certificate says that it was issued to "*.azurewebsites.net", not to our domain. So seems like the default Azure certificate is used instead of ours.
At the same time our second website works perfect with "https", and the certificate shown is correct. I re-installed the certificate to both sites and re-created SSL bindings using SNI SSL, but it still works only for one of them.
Any ideas on what can cause this?
In the Azure website configuration switch from SNI SSL to IP Based SSL.
Once you do that you should have a Virtual IP Address that can be found in the Dashboard tab of the Website on the Azure portal.
In your web hosting provider make sure the www and # records point to the Virtual IP Address instead of pointing to your xxx.azurewebsites.net URL.

Resources