Let me preface this post by saying that I could be completely wrong… I just want to rant and say those expensive Extended Validation SSL certificates are a big scam! All certificate authorities offer some sort of Extended Validation Certificate, it usually cost two to three or even ten times a normal certificate. So, these certificates are more secure right? NO!

Verisign currently offers 4 different types of SSL certificates, the highest priced is 1500$/yr (with a multi-year discount). The cheapest is 400$/yr. So the 1500$ version is more secure than the 400$ version, right? Well, it depends on what you mean by “more secure”. The simplest answer is no! Each of these SSL certificates can have an encryption level up to 256-bit (pretty much the highest available to date). What does that mean? Well, basically if a person orders a 256-bit cert, it would take a hacker a billion years to crack. What I don’t understand is Verisign actually allows people to order 40-bit SSL certs in their cheapest and 3rd most-expensive certificates (which is much more insecure). So what do you get with the most expensive SSL certs? Well, the person ordering it gets a bunch of services, none of which affects the actual SSL certificate.

GeoTrust also offers four different types of SSL certificates, the highest priced is 500$/yr and the cheapest is 150$/yr. The 500$/yr version is a wildcard cert which allows them to buy one certificate for multiple subdomains (e.g. www.domain.com and portal.domain.com would use the same cert). The next cheapest is the 300$/yr version which should technically be considered the “highest” priced version, since multiple subdomains is actually a useful feature. And again, the encryption level for each type of these certs is up to 256-bit.

I could give more examples from various other certificate authorities. I recently wrote a post about my experience purchasing an SSL Certificate from CheapSSLs.com. I bought a 3-year, 256-bit SSL certificate from PositiveSSL for only 30$… total! So what is the difference between the certificate I purchased and the certificates you can get for 150$-15000$ from the “other guys”? NONE! They both have the same encryption level, they both will tiake a hacker a billion years to crack.

Yet, time after time I see people being duped into buying these expensive certificates. I’ve heard stories about how purchasing the EV (extended validation) certificates have increased a sites conversion rates by 87%! Yet, I have never heard a single consumer tell me that they only buy from sites with the “green url bar”. Pretty much the only “benefit” you get with the EV certificates is a “green url bar”. Maybe I’m completely wrong, or completely insane, maybe I know too much about encryption, or not enough about consumers. With the EV certificates, it takes longer to get your certificate because you have to prove that you are the site owner (usually by phone/fax). With the cheaper version, you only have to have a valid administrator email address for the domain you’re purchasing from. In my opinion, both of these verification methods can be social engineered (one is not more secure than the other). So tell me, am I wrong? Is there really a practical benefit in purchasing the more expensive certs from the “other guys”? Are my 10$ SSL certificates less secure than the 1500$ certificates?

To further support my claim, Comodo actually offers a free SSL certificate (that has a 90-day expiration date). It too has up to 256-bit encryption and they claim that it is “a fully functional SSL certificate trusted by over 99% of browsers.” Of course, it’d be better to go with a paid version that gives you at least one year, that way you don’t have the hassle of renewing it every 90-days… but kudos to them for being so forward thinking.

The best you can say is that the more expensive certificates require sites to go through more red-tape and hoops to verify they are who they say they are, which is what makes them more secure. The certificates themselves are not more secure though, they all offer the same encryption level, which is ultimately securing your data.

P.S. There are malware and methods out there that can bypass all these security methods, whether you’re using an EV or a 10$ cert on your site.

I have a back-log of posts that I’ve been meaning to write and this is one of them… A few months ago I found myself in the position of needing to purchase and SSL certificate. This is nothing new to me, I’ve purchased many for many people, but never any for myself. I usually use Enom (one of the companies I consult for has a reseller account) or I use GoDaddy. GoDaddy usually has some pretty low prices but their user interface is horrible. Seriously, the first time I used GoDaddy to by and SSL cert took me like an hour to figure out what I was suppose to do.

I also didn’t want to spend an arm and a leg for a basic cert. If I could get it cheaper than what GoDaddy sells them for I was going to go for it. I did a basic Google search and happened upon a site called “CheapSSLs.com“. CheapSSLs.com had a Commodo PositiveSSL cert for 8.95$/year…. 8.00$/yr for a 3 year cert! The only problem is I did not have a clue if CheapSSLs.com was a reputable company. I asked and searching around for people with negative experience. The only bad press I saw was some guy who clearly had no idea what happens when you order an SSL cert, and even his experiences ended on a high note with compliments to their customer service.

Well, I figured, for 36$ and 3 years of SSL protection, it was worth a shot. So, I held onto my hat and slapped down the cash plastic. It was super simple to purchase and much easier to setup than my experiences with GoDaddy’s UI. I was up in running in no time.

I was a little leery at first of the site named “CheapSSLs.com” but my experiences have definitely swayed me. I will be using them for all future SSL purchases. Thanks guys for the great prices and great experience.

P.S. I am not affiliated with CheapSSLs.com in anyway, although if they had an affiliate program, I’d probably sign up.

Please forgive me while I rant, but the Internet Troll inside of me is starting to leak out. It happens to the best of us.

So, I have been using Rackspace Cloud Sites for about a year now and there are a few things grating on my nerves about this service. We use it as a hosting solution for our customers. Before I begin explaining what is wrong, let me explain what is right.

It is (for the most part) really simple to use. You can easily create a new site with custom plans in just minutes. Everything is white label, including their billing integration and customer support. You pay a monthly fee for a certain amount of Bandwidth, Disk Space, and Compute cycles. You are able to break it up as many different ways as you want and offer your customers plans based on packages. It is really quite simple and really great for hosting small to medium sized business websites.

One of the greatest things about Cloud Sites and Rackspace in general is their support. They have GREAT customer support reps ( GREAT = really friendly). They also have multiple ways to reach their support, like live chat, phone, tickets, email, etc.

These aspects of Rackspace is why I continue to do business with them. Unfortunately, there are other issues that I have with Cloud Sites that frustrate me to no end. Here they are…

1) Cloud Sites does not support SSH. This is a HUGE let down in my opinion. In fact, it was number one on my list as to why we should not go with Rackspace. Luckily for Rackspace, the other pros outweighed this con. However, the cons are starting to pile up. SSH is majorily important for a SysAdmin, especially if you need to do complicated thing to files. Just about every shared hosting provider offers SSH access for Linux servers. Rackspace’s knowledge base claims, “Shell access (Also commonly known as SSH access) is not offered on Cloud Sites based primarily for security reasons.”

Really? What are the security reasons? Why do you allow FTP access (one of the most insecure protocols) but do not allow SSH (a secure encrypted protocol)?

2) Limited Special Characters in passwords. A few months ago, Rackspace Cloud Sites introduced new security measures to prevent unauthorized access to their systems, namely, a “security question”. Yet they do not allow special characters in their passwords and they do not allow Secure Shell (SSH)! What really got me, was that we use Rackspace Cloud Sites for business purposes, so we share a username/password for the business. A “security question” hardly applies to us, so we had to pick a generic question/answer that everyone in our company knew. Regardless, not allowing special characters in a password is not just a problem with Rackspace Cloud Sites… they have a number of systems that do not allow special characters in their passwords. Adding special characters to your password, as well as the length of your password, greatly increases the security of your password. Basically it should be long enough and random enough to be unbreakable. The fact that Rackspace does not allow all Special Characters to be used for a password is very concerning to me.

Now, for the straw that broke the camel’s back.

3) Rackspace Cloud Site’s implementation of SSL is not well thought out, at all. We recently had a client who needed an SSL Certificate installed on their site. Rackspace charges an additional 20$/mo extra to enable SSL on a Cloud Site account. That is not a huge deal, and somewhat understandable, since most SSL Certs require a static IP associated with the domain name. Instead of a shared IP address, which is quite common (and cheaper) for web hosting.

We enabled SSL on our account and tried enabling the SSL Cert on the account. This is where things get hairy, really really hairy!

First, if you are using a shared IP address, it must be changed to a static IP address once you enable SSL for a specific site. I know this, this isn’t the problem. The problem is, Rackspace doesn’t change the IP address to a static address until you actually upload an SSL cert! NOT when you enable SSL for the site.

At first, this did not seem like a big deal… however, we had a small issue… let’s chase this rabbit for a while. Our client already had an existing SSL certificate, so we just need to copy it over. The SSL interface for Rackspace has two fields you can fill in, the Certificate and the Key. However, they have the Key field set to “readonly=true” via HTML. This wasn’t a problem for me, because I used firebug to remove that restriction and was able to upload the customers current Cert and Key without a problem. (by the way, the fact I could do this is just insane – the fact that they try to prevent people from doing this is even worse).

Ok, great, we have the cert installed but the cert was about to expire, so we needed to update the cert a short while after installing it. I went in to the back end to see about updating the cert and noticed there was no way to get the current CSR. I decided to wait until it expired, removed the current cert, get the CSR and generate a new cert. Sounds like a half-way decent plan? Nope, not with Rackspace Cloud Sites.

You see, because the IP address is tied to whether or not the site has a cert installed, when I removed the cert they automatically changed the IP of the site to a shared hosting IP. Essentially taking down the site for 2 hours! What’s worse, when I added the new cert back into the site we got a completely different IP from the one we had previously. This is completely nonsensical!

I wrote a ticket to their tech support services about this issue. They replied “I apologize for the inconvenience, when is time to renew the SSL cert we usually recommend that you let us know about it so that we can update the certificate from our end . . . . If the certificate is removed then the IP will change.”

Brilliant.

Rackspace, you really need to fix these things… I am not sure how long I can live without secure shell access, secure passwords, or an SSL system that works properly. Sorry for being a troll…

I apologize for the inconvenience, when is time to renew the SSL cert we usually recommend that you let us know about it so that we can update the certificate from our end, looks like your SSL IP is 98.129.227.192 If the certificate is removed then the IP will change.