I have a website running on IIS that requires two SSL certificates, one for the main website domain, and one for the traffic coming through a CDN (the assets are served from a different domain name). Both use SSL.
I therefore used the Server Name Indication option when creating the HTTPS bindings in IIS.
The site works fine, I know that users on IE6/Windows XP may experience an issue, but we don't have any/many users visiting our site using that combination so that's not a problem. However, it is an ecommerce site that receives postbacks/callbacks from both PayPal and WorldPay. Here is where we are experiencing an issue. It would seem that neither PayPal or WorldPay's mechanism for posting back payment information understands SNI, therefore we don't get notified that a payment has been made.
I'm not sure what the options are. IIS is telling me to create a default SSL site, but I can't find any instructions online regarding what I should be creating, or what benefit it serves.
Am I going down the right path with this? Can anyone offer any advice on a) whether a default SSL site will fix this issue and b) how to create the default SSL site?
Thanks for your time in advance.
Kind regards,
Dotdev
You don't have to have all your sites configured to require SNI.
From what you're saying, your callbacks from PayPal and WorldPay are on your main site are they?
If this is the case, you can simply edit the binding on your main site so that it does not require SNI, and make sure it is set to "All unassigned" rather than a specific IP address (otherwise it will get in the way of the SNI site).
Related
I have a webapp hosted on firebase hosting at example.com. Firebase provisions a SSL for the root domain. I now connected a ghost blog hosted on heroku at subdomain blog.example.com. I do process credit card payments through my webapp (root domain). Now I am unclear if i should purchase a SSL certificate from third party and provision it with my subdomain(blog.example.com). Is it required for my blog? can it affect my root domain security? WOuld a free SSL from something like Let's encrypt me enough for the blog subdomain .
The short answer is that: No, your blog being unsecured won't affect your webapp's HTTPS security on the root domain (actually called the "apex domain", although usually www.example.com is also made to work the same as the apex domain in web browsers).
When someone visits your secure webapp via the domain example.com, the webapp will present to the client a certificate that is only valid for example.com (and maybe some/all subdomains) that was signed by a certificate authority that most clients keep in their root trust store. This verifies to a decent degree of certainty that the page they are loading is actually from the person/organization that owns the example.com domain. The client/server then do a key exchange and then start enciphering the acutal payload of the HTTP session. This ensures data between the client/server hasn't been modified, and the connection cannot be eavesdropped upon.
You can run other services at blog.example.com or somethingelse.example.com and that wouldn't affect security for users going to example.com.
The plausible reason that you might want to use HTTPS on your blog is if your blog contains links to point users towards your secure site, and you want to make sure users always get directed from those links appropriately. Since your blog is unsecured, anyone with a privileged network position can modify how your blog looks to someone that loads it. State or ISP actors could modify how your blog looks almost anywhere, but even a simpler example of a malicious user at a coffee shop can affect how other browsers at the coffee shop load unsecured sites virtually undetectably. Imagine if your blog contains a link "click here to go to my main site and give me money" but the link was modified to go to a phishing site to allow the attacker to steal users' passwords and/or money.
Only you can decide if this means your blog should have security. While setting up HTTPS can be more work, encrypting everything by default certainly can only help, and many people have undertaken this mantra in the past few years. Certainly Let's Encrypt would be good enough for this.
So I've moved a website to another server (from wordpress) and have transferred the domain. Previously, it had a ssl certificate in wordpress, but not now (not needed). So now, when I try to access it in a browser, it automatically redirects to https. I know how to remove it from the browser cache, but the problem is, all the users that had accessed the website before will have the same problem and they won't know how to solve it or won't be even interested in doing so. My client could be losing a lot of visitors because of that.
Is there any way to solve that without buying a ssl certificate? I only need to solve the browser cache problem, the website is all new and everything else works fine.
Thanks
No, you cannot.
The mechanism you refer to is known as Strict Transport Security, and is specifically designed to prevent what you are trying to do.
However, you do not have to buy a certificate, you can get them for free using Let's Encrypt.
I have a question regarding CloudFlare's new Flexible SSL. I am on a free account there, so I figured I'd ask the community here before submitting a support ticket (since they don't appear to have a forum).
How do I properly handle a forced SSL redirect? I want all traffic to my site to use SSL, but right now it's bypassed. CloudFlare is enabled, and manually going to https:// works perfectly, but what is the "proper" way for forcing SSL? Do I need to use my domain registrar to redirect all requests to https? Not a problem if that's the case, I know how to do that, but I don't know if that's the "proper" way.
You could actually use PageRules to force http:// to https://
You should also make sure you don't have any mixed content issues.
Note: We don't provide a forum because we don't want people sharing sensitive information (server IPs, etc.) in a public arena. Everything is handled via support for that reason.
Question in the simplest way possible: I have a website which I want to make capable to use https - how to do it?
I heard about Google and its super powers, but the amount of results treating about ssl and https and so on, is too d* high. I'm really afraid to end up with incompatible certificates or empty bank account because of choosing wrong article or something out there.
I politely ask you to help me find the right articles about this topic. "Where do I start, where do I begin" as Chemical Brothers have sung.
I have an account on shared hosting
the very goal is to let users use my website through the https connections
I have one domain
all of images, javascript, css files are on the same domain
I'm aware of fact that maybe the best articles are right before my eyes (even now as I'm writing this question), but please - be understanding. I don't even know what should I know in the first place.
Thank you in advance for any guides.
First of all you need to create an SSL certificate. There are lots of sites out there that do it http://www.selfsignedcertificate.com/ or http://www.godaddy.com.
Once you have a certificate you need to install it on your web server. Depending on Windows or other OS you will do this differently.
Lastly you will configure you website to use https (port 443) rather than http (port 80). This is configured with IIS or Apache directly.
Hopefully this link for windows and this for Apache helps a bit too.
If you are using another hosting application, just Google: install ssl certificate [myhostingApplication]
Update:
For shared hosting this will more than likely depend on your hosting provider. If you don't have access to IIS or similar, you more than likely will have to contact your provider directly. I use shared hosting with GoDaddy and they say:
NOTE: If you want to install an SSL certificate on our shared hosting, Website Builder or Quick Shopping Cart®, you must purchase one of our SSL certificates. We do not install SSL certificates from other providers on our shared hosting accounts.
Your provider may be the same. So do be careful.
When I click on myAccount->SSL Certificates it redirects me to a page where I need to purchase one from GoDaddy. Upon purchasing one, I can then manage it from SSL Certificates on myAccount page.
Your provider may be different, since you haven't mentioned who they are, you may just have to scour their knowledge base.
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.