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
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 have a SAAS application on node express. The app creates tenant sub-domains for each sign up like mybiz.ourgreatapp.com.
We want to allow the users to point a custom domain at that account/url, ie a domain they have bought.
somedomainibought.com---->mybiz.ourgreatapp.com
We also need that domain to be HTTPS.
Uur domain, and wildcard sub domains are SSL.
So: https://mybiz.ourgreatapp.com: works.
We have tried to solve the problem using https://www.cloudflare.com which works for our sub-domain routes but we can't set it up to use customers domains and point them at those routes.
How can we achieve this?
To create certificaes for different domains
You need to solve 2 problems:
that your customers should point their domains to your IP/domain in order to use your service. Solution for it: you can create a dedicated domain like cname.ourgreatapp.com. If customer wants to use his own custom domain - he should point his domain (in 99% cases it will be customer's subdomain) to your CNAME. In 1% cases when customer would like to attach domain - better to provide also public IP for such customers. As not all DNS providers support using CNAME for 1st level domain
that you need to issue certificate for the customer. When you issue a certificate, you must prove your rights for this domain (different certificates authorities provide multiple options in order to do it). Luckily when you already have a customer who already pointed to your CNAME - you can use "HTTP validation type" (when you should provide specific text at some URL and CA verifies that secret value is there by doing GET request. For example, free LetsEncrypt certificate provider will verify specific value at the URL customersdomain.com/.well-known/acme-challenge/)
This second step I suppose is too heavy to be handled by your node-express application. Better to extract SSL-signing logic to a separate layer, even to a separate micro-service.
In order to automate this process, you can create a service which will request SSL for all your customer's domains (for example by implementing ACME protocol, requesting certificates from LetsEncrypt). And setup proxy server which will proxy requests from all customer's domains, getting data and signing the responses with proper certificates.
Also you can check third party solutions which already do this from the box. For example, Kilo SSL, Cloudflare etc. I didn't try doing it with Cloudflare yet, but just checked that it's easy to do with KiloSSL
You can set up a reverse proxy (using nginx for example). Configure a virtual host with server name somedomainibought.com that does a proxy pass to https://mybiz.ourgreatapp.com/. Configure this virtual host to use ssl and listen on port 443.
Then, the Zone file for the domain somedomainibought.com must be configured with an A record pointing to the IP address of your reverse proxy.
This question has come up at my job a few times, and I was hoping to get some community backing.
We are working on a Single Page WebApp, but require that the data coming from our services API be secure to prevent snooping of the data. We are also trying to iron out the prod environment details for where our SPA will be hosted. One of the options is using something like Amazon's S3, which doesn't support SSL (to my knowledge).
There's a group that believes the whole site needs to be hosted over SSL. However, it's my understanding that SSL will only protect the transmission of the data. So the point I'm trying to make is that hosting the services from an HTTPS site and the client code from non-SSL based URLs will be just as secure as hosting everything from an SSL site.
Could anyone clarify this for me?
Thanks in advance.
Yes, SSL just encrypts the transmission of the data, and does not offer any type of protection of the runtime environment on any client-side code.
Now, it is generally considered a best practice to host everything over SSL, for these reasons:
Users can get warnings that a site is transmitting data with an untrusted source if parts are from SSL and parts are not.
Any cookies, will be sent in the clear when requesting the non-SSL files and may contain information that should be kept private.
I am writing an application for a business who have an existing website.
I would like the application to be behind SSL, and on my server - so completely separate from the existing business's website.
So for example, they are: http://www.dogsittingservices.net - pointing to their website, on their host.
I would like to be able to have https://secure.dogsittingservices.net - pointing to the web application sitting on my server.
Is this possible at all? If so, who would have to order the SSL cert - the current business for www.dogsittingservices.net - or me? How could I order a certificate for a domain I don't own? That's my dilema.
Thank you for any guidance/advice,
Mark
UPDATE following #EJP answer
So are these the steps I would need to take:
The business that has the website would setup in their DNS:
secure.dogsittingservices.net
They would then point that DNS to the IP address of my server
I would then setup a website on my server with the name: secure.dogsittingservices.net
I would then generate a CSR for it from my server
I'd then give the CSR to the business that I'm doing the work for
The business would then have to use the CSR I generated from my server, to order the SSL
They would then send me the SSL key/code to me to apply to my server
Is that how this is normally achieved?
Thank you,
Mark
They have to obtain their own SSL certificate. That's the whole point of them, that they definitely identify the business they are issued to.
You can also have one SSL certificate with multiple site-use, as an option. Read up more on SAN certificates as it may become relevant to your solution. This would allow you to share the certificate and suit both hostnames. You can also do a wildcard certificate as well if you may have more hostnames for that domain in the future.
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.