I need to provide SSL to my Web Service that runs on IIS (ASMX web service).
As I understand there are 3 ways to do that:
1) create my own certificate using IIS
2) buy it
3) get some open source certificate
For instance my Web Service has constant IP and communicates with only one web site on client side (client is in PHP).
Can someone give an advice, what is the best way for me to provide it and what are advantages and disadvantages of 3 ways to do that, or just point to some article for complete beginners in SSL issue.
Thanx for assistance!
Creating your own cert is useful only if your end users are either completely uncaring about security or they have some other way of verifying the validity of your server - generally an internal network or something similar.
The free cert issuers tend to be unrecognized. This has the same effect as self-signing.... i.e. pointless since the end user will get the same warning messages.
There are very inexpensive options though. I've used GoDaddy before # USD $13 a year.
Here's a link to all the trusted certificate authorities that Mozilla adds to FireFox:
http://www.mozilla.org/projects/security/certs/included/
IE and Chrome have similar lists.
Related
i have seen many of commercial websites, have compromised their URL with company name as display above. i need this kind of thing to my web site too. can anybody advice me?
This website is using Extended Validation SSL certificate and the browser may or may not represent this in a special way to acknowledge for the higher security of this website.
In general, the EV certificate guarantee higher security, because the Certificate Authority that is issuing the certificate is responsible to verify that the purchaser of the certificate is the same as the legal owner of the domain + some additional info. And it is more expensive.
This is an Extended Validation SSL certificate.
They're much more expensive.
That shows that a SSL certificate exsts for the website you are on. (SSL Encryption means that information that is passed between you and the website, like passwords, will be fairly well protected from spying by internet "hackers.")
You can google "free ssl certificate" and find providers that assist you in setting up a free SSL certificate. This is a good idea for various reasons and not that difficult to do.
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
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'm currently researching how to implement SSL connections through Google's PageSpeed Service. I have been accepted into the program; but I'm having issues conceptualizing how SSL connections will work.
I am using IIS 7, and have production certificates already for multiple domains. Google states you can add up to 50 domains... but did not specify how many could utilize SSL.
Will all of my domains be able to serve SSL connections with Google
PageSpeed?
Do I need new SSL certificates?
If not, do I upload the private or public part of the certificate to Google?
How do I get these keys out of IIS?
Do any certificates from Google need to be installed on my server?
The SSL guide offers little in the way of hand-holding.
https://developers.google.com/speed/docs/pss/SSLSetup
I'm hoping someone out there has gone through this before and can guide me.
As I said before, we have several domains; and I was planning on using one of the less trafficked sites for SSL testing. I don't want to lock myself out from having the ability to add the more important domains I manage.
Thanks.
1.Will all of my domains be able to serve SSL
connections with Google PageSpeed?
Answer 1
What I saw in the tutorial is that it supports one single host:
Before starting the SSL setup, please note that PageSpeed Service
supports the following certificate types:
Single Domain/Hostname
Self-signed
Wildcard
Subject Alternative Name (SAN) / Multi Domain
from https://developers.google.com/speed/docs/pss/SSLSetup
2. Do I need new SSL certificates?
Answer 2
Yes you need a new certificate and you need it to be signed it is described in this part :
Generating a certificate signing request
of : https://developers.google.com/speed/docs/pss/setup
5. Do any certificates from Google need to be installed on my server?
Answer 5
No, you need to upload your certificate to Googles server like described in below :
5. Upload Certificates
in https://developers.google.com/speed/docs/pss/SSLSetup
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.