I was evaluating appharbor and azure framework or a cloud application.
I came across an article in this url: http://blog.appharbor.com/2012/06/10/some-notes-on-the-recent-azure-launch , which says
Azure Web Sites has no way to add your own SSL certificates at all. If your app needs SSL, you’re stuck with running on the Azure subdomain and piggy-backing off their certificate.
I am a little confused here and so the question:
1) Does this mean that I cannot register and use a ssl certificate for my domain (eg: www.mydomain.com) if my application is hosted in azure?
If that cannot be done- isnt this a fairly basic requirement for a secure web application? why is it not implemented in azure?
2) Azure articles talk of shared ssl certificate. So, if I use a shared certificate, what will the user see in certificate details? will they see something like myapplication.cloudapp.net?
This is true as of today. But please do note that Azure Web Sites is a preview feature and things do change. Having a custom SSL certificate for an Azure Web Sites is something that the team in Redmond is definitely after (check here). Also, please do note that this limitation is only valid for Windows Azure Web Sites. Website addresses usually maps to myapp.azurewebsites.net.
This is not the situation with Windows Azure Cloud Services (that maps to myapp.cloudapp.net). You check some articles and sample how to configure custom SSL for Azure Cloud services here and here.
Azure websites now do support SSL certificates, with the ability to buy an SSL certificate or bring your own.
see this article for the configuration:
https://azure.microsoft.com/nl-nl/documentation/articles/web-sites-configure-ssl-certificate/
Also free SNI certificates are available as of now for Basic, Standard and Premium App Services:
https://azure.microsoft.com/en-us/updates/ssl-connection-pricing-changes/
Related
I have researched a lot before posting this question. I have a website that runs on HTTP. We are currently using ASP.NET webforms.
My boss wants to update the payment gateway to use Stripe. Stripe wants the payments page to be running on HTTPS rather than HTTP. So I want to make my website HTTPS.
There are a lot of articles out there to make your website https with your own self signed certificate. However, I couldn't find relevant Microsoft docs for doing the same thing in a live production environment.
My question is how would I do that in a production environment where you do not have ISS control?. I understand that I will have to buy an SSL certificate from a verification authority. Currently I am using FTP to replace the bin files and the modified files to make changes to the website.
I was wondering if there are any C#,ASP.NET veterans out there who can guide me in the right direction.
To run a web site with a certificate, which is a requirement to use HTTPS, you must be able to use IIS administrator to install the certificate on the web server and bind it to the web site on port 443. You could maybe possibly get it done without IIS admin by using PowerShell, but the user account running PowerShell would need the same permissions as if you did it with IIS admin.
Bottom line-- if you do not have any access to IIS admin at all, it is not possible to complete this task by yourself.
If your web site is hosted, you will need to approach the hosting service provider for instructions on how to request and install an SSL certificate for your web site.
Say, for example, I have an Azure web app named MyApp and is hosted on Azure as MyApp.azurewebsites.net. It's my understanding that there is nothing I need to do to secure the URL with SSL, as it's done, by default, with a single certificate. So I can already have my users access the app via https://MyApp.azurewebsites.net, and it will be secure right out of the box.
However, say I have another URL named www.MyApp.com that I want to point (redirect) to https://MyApp.azurewebsite.net. Do I have to secure www.MyApp.com with a certificate?
Do I have to secure www.MyApp.com with a certificate?
Yes, we could get more detail info from the official document .
To secure your custom domain name with HTTPS, you bind a custom SSL certificate to that custom domain in Azure.
Before binding a custom certificate, we need to do the following:
Configure the custom domain - App Service only allows adding a certificate for a domain name that's already configured in your app. For instructions, see Map a custom domain name to an Azure app.
Scale up to Basic tier or higher App Service plans in lower pricing tiers don't support custom SSL certificates. For instructions, see Scale up an app in Azure.
Get an SSL certificate - If you do not already have one, you need to get one from a trusted certificate authority (CA).
Yes, if you use a custom host name, then you will need to have a certificate for it. There is really no way around this, based on how SSL works.
We have front and back end cloud service that communicate via WCF services which are secured using certificate credentials. The problem we are having is that the request fails with the following error:
verb="POST"
authenticationType="NOT_AVAILABLE" activityId="{00000000-0000-0000-0400-0080000000F7}"
failureReason="STATUS_CODE"
statusCode="403.16"
triggerStatusCode="403.16"
(From IIS failed request tracing)
I believe the issue is as described here:
https://support.microsoft.com/en-gb/help/252657/iis-5.0-http-403.16-forbidden-client-certificate-untrusted-or-invalid
(That the server does not trust third party CAs by default. )
If I do as described in the link the issue is resolved but the cloud service isn't part of a domain and I don't know how to apply this setting as part of the deployment or programmatically as part of the start-up.
What I also find strange is that this issue doesn't seem common even though I presume securing WCF communications on Azure cloud services using certificates isn't unusual, so I wonder if the issue is a symptom of something else I am doing wrongly.
I want to migrate an existing On Premise WCF service to Windows azure without asking clients to change anything in thier application like endpoint URL, certificate etc.
PLease let me know if this can be done?
In principal - yes.
The Endpoint Url is dependant on you controlling the domain and forwarding the URL over to Azure (for us, we use a CNAME redirect to the Azure URL). More details here.
For the certificate, as long as you've got an exportable version of the certificate with a Private Key, it should be a matter of uploading the certificate to the server that matches the endpoint URL. More details here.
So, all in all (with these changes in place) it's just a matter of uploading the certificate, redirecting to over to Azure and then letting DNS do its thing. If in doubt, certificates are buttons to purchase, so use that for testing purposes to prove the concept.
We have a multi-tenant website where we use a wildcard SSL cert to give people a subdomain to our site. Some of our customers would like to use their own domain, but I'm concerned about how we would manage each customer's certificate as our business grows. Currently the certificate resides on the web server, which means loading all of the certs to each web server as we add them.
I'm aware we could introduce a dedicated SSL device in front of the web servers, but are there other options to improve the management of these certificates?
I'm a Microsoft Technical Evangelist and one of my partners had exactly the same challenge.
I have created a sample source code that automates and manages SSL certificates for multiple domain bindings using a new IIS 8 (Windows Server 2012) feature called SNI, which is a kind of SSL hostheaders.
All you will need to do is to reuse my code (it's quite simple) and upload your custom SSL certificates to the blob storage, or you can write your own provider to fetch custom domains and certificates from your database.
I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/
You could make your clients deal with their own certificates and make them run there own https site. They can serve a page containing a single frame with your content (over https). The users will see their domain and their certificate and the browser will load the frame without complaining as long as the frame contents are also loaded over a valid https connection. I created a quick an dirty test page so you can see it in action.
This solution will 'break' the address bar as it will keep the url of the page containing the frame. Depending on the type of site you're running this might be a showstopper.