My SSL certificate is not verified on a subdomain of cloudapp.net - Classic Virtual server at Azure.
I setup everything in my IIS, and my port rule 443.
Could the subdomains at cloudapp.net not work with HTTPS at all?
Could the subdomains at cloudapp.net not work with HTTPS at all?
I tested it recently on my side and I make sure that the subdomains at cloudapp.net could work with HTTPS. Following are my steps.
Step 1. Generated certificate and installed it to IIS. I created and used a self-signed certificate for testing. I generated the .pfx file according to ways described in following link.
Generating a Self-Signed Certificate for Windows Azure Cloud Service
After that, we can upload the certificate to IIS of VM.
Step 2. Add HTTPS binding to your IIS.
Step 3. Enable 443 port for inbound rules and outbound rules.
Step 4. Add 443 endpoint for your VM.
Related
I have a domain purchased from Godaddy. Then a Virtual Machine setup on Azure with an web application installed on it.
So thus far I have:
An Azure VM with an application running on it, lets say the ip for the VM is 12.3.456.789
A domain name I purchased from godaddy, e.g mydomain.com, I then created a subdomain for e.g sub.mydomain.com
I then added an SSL certificate to this subdomain which worked fine, after I changed the DNS A record for the subdomain to the ip address of the VM 12.3.456.789, also the application on the VM is accessed on port 4000. So https://sub.mydomain.com:4000
The issue is that when I access my domain via https I get the ERR_SSL_PROTOCOL_ERROR in all browsers but when I access it via http then the application on it loads completely fine.
Any ideas on what I would have done wrong or left out in my setup?
Also if I did not provide enough information do let me know.
commercial SSL certs are always signed to include the TLD
(Top Level Domain -> in your hypothetical case: mydomain.com) !
You should contact godaddy to change the certificate to change the SAN (Subject alternative Name to sub.mydomain.com)
One example:
You order a ssl certificate for the subdomain www for your domain mydomain.com.
mydomain.com is valid by its nature (SAN -> it's the TLD)
Whereas www.mydomain.com is the SUBJECT.
Best H.
To rewrite to rule from https as you are getting ERR_SSL_PROTOCOL_ERROR please check you are correctly provided ssl cerficate SSL Certificate Checker as my SSL provided is DigiCert.
And to make Https ensure in your remote desktop in IIS manager click your virtual machine ->binding -> Https and port as 443 and upload certificate.
In your virtual machine try to add outbound security rule provide service as HTTPS and port as same in 443
Reference: https://learn.microsoft.com/en-us/answers/questions/23397/not-able-to-secure-windows-azure-vm-in-https.html
I intend to buy a wildcard SSL certificate for mydomain.com. From my ISP I map test.mydomain.com - using CNAME setting - to an Azure VM (not a simple web app) running a webserver (e.g. blahblah-vm.cloudapp.net) where I have opened port 80 and 443.
Now, my client connects to https://test.mydomain.com. Will there be any issues? Do I need to somehow prepare the VM with the mydomain.com SSL certificate or will it just work thanks to the CNAME mapping?
Does your VM have a static Public IP address? If yes, you could use A Records. Also, we can use CNAME map the Azure VM's FQDN.
Now, my client connects to https://test.mydomain.com. Will there be
any issues?
Before you connect to https://test.mydomain.com, we should install SSL certificate on your PC first.
Do I need to somehow prepare the VM with the mydomain.com SSL
certificate or will it just work thanks to the CNAME mapping?
There is no need to prepare something except install SSL certificate.
Update:
If your VM is windows, and use IIS to deploy your web server, we can use SSL certificate here:
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.
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.
We've got a Windows Server 2003 running IIS 6 where we host multiple sites with different domains. www.site1.com, www.site2.com etc.
Now one of these sites need a SSL certificate, so I ordered a certificate from rapidssl.com for the domain www.site1.com.
The problem:
After installing this SSL certificate all https request to this server, regardless of domain, gets redirected to the www.site1.com site.
FYI: This is the only site on the server that got a SSL certificate installed.
Anyone?
cscript.exe adsutil.vbs set /w3svc//SecureBindings ":443:" solved the problem.
According to this site, SSL does not support host headers. If you have more than one IP on your server, try using one IP for the SSL website and use other IPs for the other sites. If you don't, ask for another IP for your server to your helpdesk.
It's possible...
http://www.sslshopper.com/article-how-to-configure-ssl-host-headers-in-iis-6.html
http://www.digicert.com/ssl-support/configure-iis-host-headers.htm
As per post by Kulvis