So I have a certificate called azerwmetricp02.test2.com, and when I use this certificate for an HTTPS website where the Host Name is the same as the certificate URL, then I can access this website.
But now I want to add a second website to my IIS, which also use https, but I can't use the same URL azerwmetricp02.test2.com. Is there a way to use this certificate azerwmetricp02.test2.com but for two websites? let's say website1.azerwmetricp02.test2.com and website2.azerwmetricp02.test2.com?
I did try this guide, but it doesn't work, it just says that I have no access to any website: https://www.digicert.com/kb/ssl-support/ssl-host-headers-iis-8.htm
Is this even possible or do I need to get a second certificate so I have one per website hosted on the IIS?
Related
I have just bought an SSL Certificate for my website from azure. when setting up a certificate under "Naked domain hostname" i entered the domain name WITHOUT "www".
Currently if i were to view my website with https://xyz.ca, it works just fine and it says it is secure, but if enter www.xyz.ca i do not see anything.
To atleast view the website with www.xyz.ca, i have removed HTTPS:// only request. However now this makes website un-secure.
Question
1. what will be the best way to make www.xyz.ca secure using the same certificate that i have bought?
2. if there is any other solution available, that will be fine too.
I am attaching some screenshots to understand better:
In fact a cert CAN support MANY domains. Now, whether this is something that you can add for free with the SSL provider you have chose is a different question. Certificate Subject Alternate Name(s) are what is used for this. For example the cert for this site allows stackexchange.com AND stackoverflow.com and a number of others and sub-domains too.
A valid SSL certificate must match the access FQDN domain name.
One Standard certificate only could be used for one FQDN domain name, such as www.xyz.ca while one WildCard certificate could be used for all like *.xyz.ca FQDN domain name, so usually we use the same WildCard certificate for all different services. More information about SSL Certificate Names
As the comment point it out, instead of buying one via the Azure Portal, you can get a free one via letsencrypt.org
Update
When you purchase an app service certificate in Azure for a root domain, by default, Azure supports hostname as a root domain name and www subdomain. You do not need to purchase another certificate. In this case, you already have two hostnames assigned to the site. You just bind the certificate for each. If you don't see the domain name(s) in the Hostname dropdown, try refreshing the browser page or change another browser.
I used to run one of my websites (EyeDentity.Online) from a Windows VM on Azure. I had an SSL Certificate in IIS up to run it and all was well in the world.
Since I moved the Website to the Azure App Service and installed the SSL Certificate in Azure whenever I go to the Website for the first time in a browser session it tells me that the certificate is invalid.
It appears to quote the standard AzureWebsites.NET even though my certificate is bound to my website
How can I get this warning to go away as it may be scaring away users!
Things to check:
You must be on Standard or Premium level to bind to cert
Check SSL bindings section of Custom Domains and SSL blade to make sure you've
bound the domain to the right cert.
The description of the problem sounds like number 2 here. If you haven't changed this, then it will bind by default to the azurewebsites cert and not yours.
Some docs here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/
Your cert is for azurewebsites.net and not EyeDentity.Online. You should get a wildcard cert for your domain name:
*.azurewebsites.net should be: *.eyedentity.online
ref: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/#1-get-an-ssl-certificate
"Before requesting an SSL certificate you must first determine which
domain names will be secured by the certificate. This will determine
what type of certificate you must obtain. If you just need to secure a
single domain name such as contoso.com or www.contoso.com a basic
certificate is sufficient. If you need to secure multiple domain
names, such as contoso.com, www.contoso.com, and mail.contoso.com,
then you can get a wildcard certificate, or a certificate with Subject
Alternate Name (subjectAltName)."
I am attempting to add ssl to my custom domain for the windows azure websites. I have configured everything properly according to the guides, but for an unknown reason when I attempt to access my website via HTTPS, it returns with a connection denied error. the redirect still works perfectly fine with a standard HTTP request.
for reference (https://www.cryptoalias.io)
short version of method (in case I missed something):
bought a SSL cert from comodo.com
generated a .pfx from the .cer they issued to me (using iis)
uploaded .pfx to azure
verified cname: created custom domain redirect to azure
bound ssl to custom domain
configured A name redirect to the VIP azure issued me. remove cname redirect
attempt to connect to https = nothing, http works.
sorry I realize this is rather short on information, but I'm not sure what more I could provide besides the actual SSL cert.
You need to configure your cert on 2 domains: cryptoalias.io and www.cryptoalias.io. Because if you go to https://cryptoalias.io/ your cert works fine.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
Currently customers have sites on my domain like https://customername.myapp.com. I'd like for them to be able to upload an SSL cert and then access my site via https://myappname.customername.com - how would one go about doing this programmatically in .NET/IIS 7?
bump
So I might have an answer for you but it doesn't necessarily involve .NET/IIS 7.
I'm not quite sure what the end goal is here, but I'll take a stab at it. It sounds like you want customers to go customername.myappname.com and have it show myappname.customername.com's content? You don't simply want to redirect them? Do you have a trusted SSL certificate for myapp.com? If you do, then there's a way you can extend that trust to the myappname.customername.com websites.
Assuming your customers don't want to have to pay for SSL certificates for their websites, you could have them generate self-signed certificates (or create your own CA and sign their certificates) and upload them to your website. Then, using a combination of JavaScript and Flash you could do cross-domain requests from your website to theirs over SSL.
The way this would work:
A customer would go to your website myapp.com. From there (or from customername.myapp.com if you have a wildcard SSL certificate), they could login or just click on their name. Doing so would load a page with a JavaScript implementation of SSL, Flash swf, and the SSL certificate associated with that customer. Then the JavaScript SSL would do cross-domain ajax requests to the customer's site and show their content on myapp.com. This would enable a secure connection to their website via your website.
There's another bit of complexity that you might not be able to support in your use case, however. You need your customer's websites to be able to serve an XML file that contains a Flash cross-domain policy. This policy would specifically grant your site access to theirs.
The JavaScript TLS (SSL) and Flash you would host on your website are part of an opensource project called Forge. This blog post explains how it works in further detail and provides a link to Forge on github:
http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/
Most of this stuff is done using client-side JavaScript, but you'd use .NET/IIS 7 to provide your customers with the page to upload their SSL certificate.