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
Related
I have instance running in oracle cloud and domain in Google Domains. I want to enable HTTPS, So I added A record in DNS with HOST name www and valid ip address
I want to use the let's encrypt SSL for the domain. I followed this link
https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal
But still HTTPS is not working.
Note: I have domain ending with ".dev".
Added A record in DNS
followed this link
https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal
I have an api served at a hypothetical address http://82.12.61.115:8000 (note the port).
I want to have a domain point at that IP address and then secure that domain with an SSL certificate.
Is there any service I can use (e.g. AWS) to do this without buying the domain and SSL certificate? Since it is just an API, it doesn't have to be pretty, it can be a subdomain of another domain as long as it's secured.
On a related note, will using port 8000 be a problem (as opposed to 80 or 443)?
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.
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:
My company changed names recently, so along with that came a new domain. Both the old site and the new site are HTTPS and are on the same server using separate DNS entries.
I setup a 301 redirect which works great if people go to oldsite.com, but if they go to https://oldsite.com they get an SSL error.
Is there any way around this? Hopefully through DNS, server config, or htaccess file.
With TLS/SSL, only one certificate can be presented by the server per IP address. So if oldsite.com is using the same IP as newsite.com, the certificate for https://newsite.com will be the one sent to the client, which will (by definition) raise an SSL error for https://oldsite.com.
To have both oldsite.com and newsite.com both active, you'll have to have separate IPs for each. These can reside on the same server, with some (possibly complicated) routing configuration depending on your server's OS, to ensure requests to each IP are replied to from the same IP. However, even with DNS entries for both, you cannot share an IP address with multiple HTTPS domains.
Edit: You could also use virtual domains (exact config dependent on which web server you're running) to present the certificate for oldsite.com, then send the redirect after the TLS session is in place. I'd have to know which web server you're using (Apache, Nginx, Lighttpd, etc) to give a config example, though.