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.
Related
I have created Windows Server VM in Azure and deployed my site to IIS, which is now accessible at https://mysite.westeurope.cloudapp.azure.com/
however I get certificate error when I try to visit it from outside the vm.
how do I configure the VM to have proper https without certificate errors (just like app service - mysite.azurewebsites.net)?
As the comments from micker #micker, you can't get an SSL certificate for this subdomain westeurope.cloudapp.azure.com which is owned by Microsoft.
Since you host your websites on Azure VM, you could purchase a domain then get an SSL certificate for your own domain, then bind the SSL certificate to your custom domain in IIS on the Azure VM. You can either purchase that certificate through Azure or an external provider or get a free SSL cert from Let's Encrypt.
However, if you just want to have a test in your test environment, you can use a self-signed certification with this DNS name like vma.centralus.cloudapp.azure.com. You can follow steps in How To Create A SHA-256 Self-Signed Certificate on the Azure VM then export this cert .cer format file on the Azure VM and import the .cer cert under the mmc---certificate---local machine---Trusted root certification Authorities on the machine where you want to access the websites. Please note this It's not recommended to use self-signed cert in your production environment.
I had same issue, and I found resolution without custom domain using following additional azure settings.
create Azure WAF, add custom rules to deny if not in IP list - this is if you need ip whitelisting, useful if your main domain uses akamai or other edge routing to point to external hosting of subdomains, you can use whitelist to restrict access to the akamai or other servers, though this takes some big lists you must paste of ranges one row at a time. Set any other web app firewall rules you want enforced for allow/deny.
Create Azure Front Door named like you want as an endpoint url e.g. myappfrontdoor will make myappfrontdoor.azurefd.net. in backend pool specify the your public-ip shared dns name (see step 3) like myapptest..cloudapp.azure.com.
This is the important step : in Settings at top of front door designer, disable cert validation. in routing rules config, no condition, forward to backend pool setup in prior step. This ignores the fact that you cannot cert your cloudapp.azure.com endpoint, and wraps it with a *.azurefd.net certificate.
In your azure firewall, Edit NAT rules, set rule name myapp-web-fd-... , tcp, ip address, 147.243.0.0/16 (this is Azure's front door backend ip range). destination should be the firewall's own public ip. destination port 443, translated address should be the target vm's azure internal ip, target port - service port.
Now you will have a site like myappfrontdoor.azurefd.net.
Note that Azure Front Door and WAF have their own pricing costs, so maybe it is cheaper for you to buy a domain. Hopefully you are also using Azure Firewall, though expensive. If not, one could point to public ip directly on NSG or on vm itself but I wouldn't skip having a firewall for a public server. There is a standing Azure enhancement request to get Azure Front Door to recognize certificates, but it was triaged 2 years ago and still not added, so not sure if it will be worked. If it ever does get worked, devs could make own cert auth and self-signed cert with expirations to more securely hook front door to azure internal vm. For now, have to rely on the front door backend setting, waf, and azure firewall to have these things routed.
There are some options in Akamai and other edge routing systems to import cert and self-created authority sort of, but I've not tried that yet, so cannot confirm this would cleanly wrap your azure site without cert errors. You can make a self-signed authority using openssl commands as noted in other posts out and about on the web.
The simplest and cheapest option is to purchase a domain and use a cname dns record to map your new domain to your Azure subdomain address - an "A" record is not required. Also per answer above, a WAF is expensive and possibly unnecessary for a test set up (but a requirement for a production website). You can use Certbot and NGINX to create a free Lets Encrypt certificate for your domain and assign it to your website.
Adding a Public IP Address, Load Balancer, and Network Security Group to your Azure Resource Group may also be required to provide access to your website. This is largely how my test configuration is set up except I'm using a Linux VM, have a single wildcard certificate, and use NGINX to reverse proxy 3 websites.
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.
Aim:
I want to use free SSL certificate on Cloudflare on the website that is current hosted on Azure.
Background
A SSL certificate has been bought from Azure, but we found that we need to upgrade our subscription before able to bind it to our website. Hence, we decided to use Cloudflare free plan that also offers SSL. The domain provider that we use is godaddy.
Problem:
I have followed the instructions here, and now on the Cloudflare, I could see the status for SSL certificate as Active Certificate. However, when I enter the url as https://mywebsite (https), it says that This certificate is not valid (host name mismatch), which is shown on the screenshot below:
Questions
Why does the current SSL certificate points to .azurewebsites.net? Shouldn't it points to cloudflare, after changing the nameservers? What does it mean by host name mismatch?
Current status for SSL certificate on Cloudflare is Active Certificate, does it mean that it's verified and currently applied to the website?
Thank you very much!
You are correct, if it is configured properly it should display the correct certificate in your browser. Possible reasons that it doesn't show correctly: old certificate cached in browser, old nameservers cached, you're not using cloudflare for the appropriate DNS records.
1b. As for the host name mismatch, you typed in example.com and it returned a certificate for a different domain. This means that the data can still be encrypted during transmission but that you are probably not communicating with who you think you are.
Not necessarily. In the article that you link is a great diagram of this process (5th image). You are using Flexible SSL. In order for this to work your website needs to go to Cloudflare's servers first. You can have an active certificate but that doesn't mean that it's been applied to your website. Make sure that the domain and/or any subdomains are on cloudflare and that data is routed through Cloudflare's servers.
We used to have a setup on IIS 7.5.
- 1 IIS has 2 websites both run on 443.
- It has different host names in the binding - site1.domainname.com, site2.domainname.com
- Both sites were bound to a wild card SSL cert - *.domainname.com,
and this worked fine for years.
Because of an audit, we had to move to a FQDN certificate.
Now when I bind the FQDN certificate on a site, it does not allow me to add a host name.
http://screencast.com/t/sowdaziJV
It says you can't start the second site as another website is already running on the same port.
This made sense until another internal team got it working. My guess is they used scripting to allow this on IIS instead of IIS GUI.
They have 2 websites running on the same port with different SSL certificate with no Hostnames.
I found out an odd thing about their setup and I was able to set it up like that too.
Have the sites with wild card certs and hostnames.
Change site one with the FQDN cert.
DON'T Change site 2 with FQDN cert.
It automatically takes the new certificate and keep the host name
They both stay up. If you look at site 2, it looks like it has a hostname binding. but if you edit that hostname is gone. See this figure.
http://screencast.com/t/z5y4n7KhGNE
Questions:
Is IIS running 2 websites on the same port with different FQDN certificate an expected behaviour?
I am worried if they took advantage of a bug. I want to be sure if this is allowed before I do this in production.
They probably turned on SNI. SNI allows the server to discern between a host name and route it to the correct site and then send back the SSL cert associated with the site. The problem is, not all browsers support SNI handshakes. SNI only started with server 2012, so the other team might be running that. Previously, IIS couldn't do this, so each site had to have its own IP / SSL cert. Now, you can run all on 443 for one site, and IIS can figure out which site to respond with by looking at the request.
I was asked to create a sharepoint web application with ssl on a server with sharepoint 2010 installed. The problem is that this port seems to be in use for hosting our subversion repository. So when i try to browse my sharepoint site, it just shows a page with my repository. I've read about installing certificates and configuring multiple sites on one port with host headers but i never succeeded to complete this job. I would really appreciate some help here.
Thanks!
Assuming you're talking about individual SSL certificates (as opposed to a single wildcard certificate), I believe each website HAS to have its own IP address. AFAIK it is not possible to run multiple websites with multiple SSL certificates under the same IP address.
Depending on who is hosting the server, you would need a new IP address to be allocated to the server, and then within IIS you use the new IP address against the hostheader of your new website. You should find that the certificate works correctly, if not then try removing the certificate from the website and re-allocating it.
You would only be able to use a wildcard certificate if the primary domains of the websites were the same (e.g. website1.mydomain.com and website2.mydomain.com).
Thomas,
I've run into a similar situation before where the requirements dictated that we use 1 ip address, but the domains will be different (eg. website1.com, somesite.org, website2.us).
You can achieve this by using a Unified Communications certificate with Subject Alternative names. Currently, Digicert offers a UC certificate that can achieve this, but some other CA's will not.
Essentially you will have 1 certificate bound to :443 on the same ip address. The big drawback to this is that if the cert goes down, all the sites SSL will not work.
You have to manually (via powershell) bind each domain to port 443 however, but the instructions are fairly simple.
Server Name Indication would be another way, but it's not even an option in IIS 6