Posted by spessex on January 27, 2014 at 9:03am
I'm currently looking at buying a SSL certificate and attaching to one of my domains. The main reason (along with encryption) is to provide more peace-of-mind for users who will providing their personal data (we are also signed up to data protection).
Can anyone provide any advice as I'm totally new to this, especially in regards to:
- green bar or not (and if not do you think the average Joe will understand the site is SSL)?
- best companies in relation to price and service?
- I need one domain to start with but will need an additional two in around nine months time so need to way-up options;
- anything to consider when using SSL with Drupal (I'm on AWS Cloud with NGINX)?
- anything else to consider with SSL i.e. does it affect performance and is this linked to the provider?
- any pitfalls to watch out for?
- please note the site is an international site but is mainly aimed at UK.
Any advice would be greatly appreciated.
Thank you
Stephen
Comments
SSL cert
Aloha,
Regarding the green bar, I would put it in correlation with the fact that you are running (more or less) an international website. If you are going to go through the authentication process, your green bar will show your company name and the origin country, which in this case would be UK. Will this make an impact on your international users? From what I've seen so far, a lot of prestigious websites prefer to use only domain authentication, as drupal.org for example.
Regarding your infrastructure: SSL is binding only to your host( also known as common name) and not to an IP address. So you can install the same certificate on multiple load balanced machines. You can easily find tutorials on how to install your cert on nginx.
Regarding performance: it will surely slow down your website. If not really necessary, you could use it only on pages with sensitive data (login, profile updates etc). Use 128-bit encryption instead of 256-bit, is extremely powerful, much faster and you will reduce a lot of cpu cycles.
Things that you should keep in mind:
- when you are buying a ssl certificate, register your common name as "www.site.com" and not ".site.com". This way you can use your cert for both www and non-www variant of your site.
- it would be better to buy a certificate for multiple years as for every renewal you will need to reinstall it.
- for convenience you could use a wildcard certificate, but this are way more expensive.
Regarding price:
- The cheapest wildcard ssl is offered by http://www.startssl.com/ at a cost of $60/2years. Haven't used them, and I would personally not use them, as I could never trust a website with such an awful design.
- For standard SSL certs, you can find good offers at namecheap.com. The best one I could find is at http://www.cheapssls.com/comodo-ssl-certificates/positivessl.html?years=5 - $5/y for 5 years registration.
Which provider to choose for your SSL? It really doesn't make a difference. A Verisign, Thawte, Digicert... sure, are more prestigious, but extremely pricy and in terms of security or recognition(most known providers guarantee 99.3% browser recognition) will not really make a difference. What matters - especially when there is a time constraint - is the rapidity with which they renew or reissue your cert.
Thank you. This is very
Thank you. This is very useful.
My Feedback to given query
green bar or not (and if not do you think the average Joe will understand the site is SSL)?
=> It is not necessary to have Green bar EV SSL but yes, it can definitely draw customer attention to browser pad lock. I would not recommend EV SSL for low budget business where only customer security is the priority.
You can always display siteseal of Certificate authority that can prove your site's SSL certificate validity.
best companies in relation to price and service?
=> It is totally depending upon your budget as SSL certificate from Rapidssl starts from $10/year (domain validation ssl) where as other CA's EV and multi-domains ssl can cost more than $500/year.
I would recommend checking price at authorized resellers like ssl2buy.com to save more on same certificates. In addition to price, you can get better services from such authorized resellers.
I need one domain to start with but will need an additional two in around nine months time so need to way-up options;
=> in that case, you should go with single domain ssl as of now and after 9 months, you should buy multi-domain SAN certificate to protect more domains.
anything to consider when using SSL with Drupal (I'm on AWS Cloud with NGINX)?
=> I am not that much experienced in this category but i am sure all certificate support AWS cloud. I recommend discuss with support before you make your purchase decision.
anything else to consider with SSL i.e. does it affect performance and is this linked to the provider?
=> Before you buy any certificate, understand their issuance process as in domain validation you don't need paper work and can be issued within few minutes to hours. Where as organization validation (EV) certificate will require some paper work to.
I am sure it will help.
http://digicert.com is where
http://digicert.com is where to buy, imho. They have the best customer service, terms, and pricing from any SSL provider I've found.
You don't need the green bar, you just need a plain ol SSL Cert, The rest of it is marketing and extra fluff that they can get away with charging for. If you want it, sure, cool. But as long as you get a strong verified validated SSL cert, its as good as any other of the same bit rate encryption.
The green box is "fluff,"
The green box is "fluff," yes, but I think it can be helpful on a site which is often copied for phishing attacks and the like. NORPs can't tell the difference between amazon.com and amazon.com.totallynotafishyphishingdomain.ru, but if they know to look for the green bar that says Amazon.com, they can have a little more confidence they're at the right place before handing over their credentials.
The Boise Drupal Guy!
In regard to performance I'm
In regard to performance I'm still trying to understand how the SSL issuing authority is actually involved. Am I correct to assume that the issuing authority actually provides the encryption and if so how does this work? Would it mean that when a visitor visits my webpage, somehow that page is also passed through the issuing authorities servers to encrypt the page and then sent back to the users? If I am in the same ball-park with this, would it mean that the level of providers (which is probably reflected in price) would have a strong basis on how much the SSL effects the site in terms of performance?
Hi
Every web browser has a database of CA public keys, so is not necessarily to directly contact the certificate authority; communication is only between the server and user browser.
It's a confidentiality thing
When requesting your certificate you need to create Certificate Signing Request (CSR) so that the CA can sign the certificate. Now to create the CSR you need a private key and most CAs allow you to use a key they generate for you.
Needless to say that in order to be really private it should be known by you and only you. So generate your key with at least 2048 bits of length and create the CSR using it. This way the CA only gets the public key and not the private one.
I just updated the config on github with:
pregenerated 2048 bits Diffie-Hellman parameters.
Better choice of cipher suites with ECDH being preferred and with fallbacks for
junkyard clients (XP and other crufty crap).
1 day SSL session cache: keeping with the Joneses Google, FB, Twitter by using
long SSL session caches.
Choice of the most "secure" EC from NIST.
Thank you for this.
Thank you for this.
Wildcard Certificate
Did you not mean to say "register your common name as "*.site.com" and not "www.site.com"."?
Hi, "*.site(dot)com" would
Hi,
"*.site(dot)com" would be considered a wildcard subdomain. I was referring to single subdomain certificates, where ".site(dot)com" is considered a reference to the domain root, at least in the DNS naming conventions. But when ordering you would probably use "site(dot)com" as a common name for your certificate.
StartSSL
Regarding startssl.com, I believe Parisa Tabriz (Google Chrome security team) mentions that she uses them regularly in her talk here: https://www.youtube.com/watch?v=sJ8EX61fFWQ&index=17&list=PLOU2XLYxmsIJb...
Performance
can be much improved by using the proper cipher suites and SSL session cache settings.
Don't use a CA supplied key please. Use your own.
I'm adding right now to my config. I'm going to add it together with
pre-generated DH parameters and additional recommendations for improving entropy.
ETA: this evening.
Thank you. Looking forward to
Thank you. Looking forward to seeing it. If you can give me a heads-up when it's on it would be very much appreciated.
PS What do you mean by 'Don't
PS What do you mean by 'Don't use a CA (certificate authority) supplied key please. Use your own.'?
Why do people keep saying not to use a CA signed key?
It's not like the CA actually HAS your key, they just sign it, So for you, if you can verify the fingerprint, it doesn't make any difference whether it's CA signed or self signed.
But for all other users, they have no way to trust your self-signed key, so they're going to get browser warnings and broken pages and non-functional AJAX and the like...
They're saying CA-supplied,
They're saying CA-supplied, not CA-signed.
A CA-supplied key means you have to trust that the CA doesn't store the private key they generated for you whether that storage is intentional or not. Allowing a third-party to generate the key for your certificate violates the trust that is supposed to be between only the user and the site because there's a chance that the third-party who generated the key may still have the key that only you should have.
Also, you can have users trust your self-signed key. Set up your own CA to sign your key, and then have the user install your private CA certificate. The browser will treat it exactly like a key signed by Verisign, Thawte, Comodo, etc. so long as the user has installed your CA certificate as a trusted CA. The browser just checks to make sure your SSL certificate has been signed by a CA in the list that it trusts.