is it usually advisable to install a single domain ssl certificate to the main domain --domain.com and use .htaccess to go in and out of ssl or to a subdomain such as --secure.domain.com. I know there are different needs for different sites but I'm asking for the average websites needs. -eg a website owner wants a secure shopping cart for their customers should they use domain.com/secure and force ssl or have ssl on secure.domain.com
I would install it on the main domain name. It sounds better to put it on a sub domain but then you technically have a whole separate website to maintain and this could be a negative rating for search engines. Also, need another SSL certificate if you want anything secure on your main site.
Depending on your back end technology (i.e. - .NET, ASP, PHP), it only takes a couple lines of code to check the page request and redirect the user to the proper page desired. For example, if a user goes to [http://www.domain.com/secure] you can redirect the request to the proper secure page (https://www.domain.com/secure) and vice versa.
.htaccess is an older technology and can be very cumbersome to use.
Related
Here is my situation:
I own and control coolwebsite.com
Many websites have a CNAME entry pointing to coolwebsite.com
For example, lamewebsite.com CNAME's a.lamewebsite.com to coolwebsite.com
There are about 50 of these other websites that point to mine, none of which I can control easily
How can I get an SSL certificate that will work with these CNAME's?
There are about 50 of these other websites that point to mine, none of which I can control easily
If you have no control over these web sites or their DNS settings than you should not be able to get a certificate for these. If this would be possible than it would be a serious security issue.
This appears to be a shared hosting kind of setup where you host the websites for clients and allow them to point their own domains to your server and use SNI or host header to serve a correct website based on domain used in the request.
More information like is above correct, where you're getting your TLS certs from, do you want to use single cert to cover everything or a cert per domain would be useful, but in general you can get a certificate with multiple Subject Alternative Names for different domain names/sites.
E.g. if you're using Let's Encrypt, with Domain Validation, you don't need control over domain's DNS, only over content served from that domain. And if people point their aliases (CNAMEs) to your web server then you already have it.
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.
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).
I'm running a dating site and not using SSL at the moment.
I've noticed major sites like facebook and twitter do not use https for login but just use plain old http, is there really any advantage to https-ing my site or it is only for cc transactions or so ?
thanks in advance.
Actually, facebook does use https for its login:
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
as does twitter:
<form method="post" id="signin" action="https://twitter.com/sessions">
You'll notice they don't use https for the page that displays the signin form. That's because it isn't necessary.
However, it's a good idea to use ssl the login itself if you can, if only because so many users employ the same password for all sites.
One solution, which I'd like to see more sites employ, is using OpenID/OAuth for login instead of requiring a username/password.
SSL encrypts the traffic between the browser and the server. So virtaully anything you want to be secure needs to be ssl'ed. Google search is even doing it so poeople can't have their search terms intercepted.
Its just the case of what YOU want secure, and if not having certain parts of your site secure will keep wanted customers away. I would think a dating site has a lot of personal demographics information that some people might want secure... just my 2 cents.
SSL is used only when transmitting sensitive data between browser and server. It's fine for major sites like facebook and twitter to use http (as long as the data is not sensitive). Most website use SSL for their login page. SSL also used by payment gateway to safely transfer payment information through the wire.
And by the way, http is not "plain old" and https is not new trend either :)
If your users are providing any sensitive data, ssl prevents it from being intercepted by a third party. If you don't use SSL, you should assume that some third party can see everything that every one of your users does on your website. If you are comfortable with them seeing this information, then keep it plain http, but if you don't like that thought, go https.
Another benefit of ssl is that it allows the use of Strict Transport Security, which not only forces https on all site activity, but also prevents a man in the middle from spoofing your site to a user and making them think they are accessing your site. Details here: http://en.wikipedia.org/wiki/Strict_Transport_Security
I work at a major ISP and am infatuated with one of your online members. By sniffing your packets, I can find out when and where she's meeting another member, rewrite the packet to change the location so the other guy doesn't show up, and then make my move.
You decide whether that's acceptable to your users.
Https is useful to protect the credential (user/password) , but it increases the network load and requires more CPU resource (encryption). Thus, it is common to use only for authentication.
Https ,with server certificate protects again phising.
Banks uses end to end application
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.