SSL Certificates - Advice in buying?

spessex's picture

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

Bogdan Nedelcu's picture

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

spessex's picture

Thank you. This is very useful.

In regard to performance I'm

spessex's picture

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

Bogdan Nedelcu's picture

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

perusio's picture

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.

spessex's picture

Thank you for this.

Wildcard Certificate

rparree's picture

Did you not mean to say "register your common name as "*.site.com" and not "www.site.com"."?

Hi, "*.site(dot)com" would

Bogdan Nedelcu's picture

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

matthewv789's picture

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

perusio's picture

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

spessex's picture

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

spessex's picture

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?

matthewv789's picture

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,

Brian Altenhofel's picture

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.

United Kingdom

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week