I just recently enabled SSL on my business website. It was anything but simple.
First of all, I had to get a dedicated server, because a bunch of other sites were running on the same server, and the hosting company doesn't offer additional IP addresses.
Then I wanted to get an SSL certificate. I picked Comodo, because they seemed to offer the cheapest full business validation certificate, but then accidentally bought a domain only certificate because their marketing was so confusing. Their friendly customer service walked me through a complicated process for changing my order.
To get the certificate issued, it took me a week to collect the documents they requested. I had to make sure my business was listed in the yellow pages, so they could send me an automatic phone call for verifying my number.
After every step in the process, they told me to log into their online management area, which was offline from time to time.
I had to confirm my email address by clicking a link about a dozen times. Half of the emails were missing the confirmation link.
Twice I got an email telling me my order will soon be processed, and nothing happened for two days. I had to open tickets in some online support area or send them emails to get them to continue processing.
All in all it took me a month to get SSL working. Now I understand why so many sites do not use HTTPS.
Someone should probably point out: most of your problems were related to doing full business validation from a crappy provider. Business validation is optional and doesn't enhance the transport-layer security benefits of using SSL.
Business validation is what you should be using for a business site. It's actually a good thing and means that the company is interested in verifying who you are.
I went through the dance with Startcom and agree with the article that the web interface has horrible workflow. However they were clearly doing their best to verify that it actually was a business they were creating an account for. For example, they ignored the phone number I gave them, and instead called on the publicly-listed phone number they found on the internet.
Except not even 99.9995% of your customers will know or care about the level of your SSL Cert.
It really does not add anything to the equation. Just extra costs and work for you.
It's been studied and pointed out that a green-bar does nothing to conversions and sales.
I suggest skipping it always, but often times a higher business type will override the suggestion of whomever has to implement it and maintain it - simply because they really don't get it or don't care about the cost (which isn't really that much, but still, you have to jump through hoops getting the docs in order).
It's been studied and pointed out that a green-bar does nothing to conversions and sales.
I'm not debating this point, but if you have some citations for this assertion, I'd love to read them. I've always heard and read otherwise.
I just completed a multiple-month-long process of converting a dynamic-domain application to support SSL-friendly URIs and implementing SSL on it's web servers based entirely on the concept of adding a green bar for boosting conversions (data isn't quite in yet to verify we did anything). I would really hope that I didn't waste multiple iterations on a pipe dream.
Those "Get better conversion rates with EV Certs" internal studies are pure marketing B.S. by the SSL vendors. Do not trust what they say.
Every single person that has tested this on his site has come to the same exact conclusion - the green-bar has no meaning to the consumer, nor do they even notice it.
Because the browser is going to check if the certificate is revoked as part of the ssl handshake. We have gotten sites being not available because the service that the browsers use to do this validation were not responding fast. The handshake took up to a minute.
I'd like to see some facts to back that up: I suspect it is bunk, another problem somewhere that has been mistakenly attributed to the certificate type (perhaps they altered other SSL options on their web server at the same time as changing the cert, or the non-EV cert uses smaller keys so takes less CPU time to process).
The EV certs contain extra information so are likely to be a little larger, but we are talking at most a couple of hundred bytes here so the extra download time getting the cert and CPU time verifying things are not going to be significant.
People do tend to have larger key sizes on EV certs (2048 or 4096 bit rather than 1024 or 2048 (though 1024 bit keys are increasingly rare even for "standard" certificates)) which might impose a measurable latency difference on a mobile (or other low-power) device due to the math involved in verifying the site against the certificate, but nothing like the order of magnitude that link mentions.
Once you click your Account, or try to login it will send you on via verified https:// regular pages and the cart does not have SSL. Possibly for speed issues
> It really does not add anything to the equation. Just extra costs and work for you.
Of course it adds something: It makes it more difficult for someone else to go buy a SSL certificate in your name. Security isn't just about driving sales, it's also about protecting yourself and your customers.
> It makes it more difficult for someone else to go buy a SSL certificate in your name
No it doesn't. Just because you wasted money on a joke process, doesn't mean "evil attacker X" has to do it too. They can just go ahead and buy a regular cert for your domain still.
I think you make a fair point on the level-of-cert point. I got the first level of their business cert offerings because I needed a wildcard cert - we still don't have the EV green padlock.
I guess I was more trying to convey that it's reassuring to know that Startcom (at least) go to some effort to investigate their verification, and it's not just a bits-in-bits-out process.
This being said, I'm in a business and if I leave and another ops person comes along, the semantics of 'business' versus 'personal' account makes their job a little easier. I'm certainly not an expert in the area of SSL, but from long experience in other fields, it's a pain in the arse managing 'business accounts' that are really repurposed individual/private accounts.
I agree it shouldn't change conversions, but I would also like to see some data supporting that. I run a lot of ecommerce sites and couldn't imagine the number of transactions not dropping if I just removed my SSL from every site.
We're not discussing whether or not you should have SSL at all. We're discussing whether it's worth getting Extended Validation, displayed as a green bar in browsers. E.g. currently at https://twitter.com you get a lock icon and a green bar that says "Twitter, Inc. (US)" — that's EV. At https://www.facebook.com you only get the lock icon — no EV.
Someone should probably also point out: most of the CAs are more or less equally 'crappy'. We've been through many CAs now and none of them has a process anywhere near 'perfect'.
Btw, Comodo customer support is rather nice. We recently bought a code signing certificate from them and they walked us through the whole process via chat, worked quite well and we were done in about 30 min.
Do you not feel that, due to the security failure in 2011, they are one of the worst? I typically disable their certificate on my machines. The CA system is totally flawed anyway, I don't know why I bother.
There are flaws with current PKI infrastructure but as you say, it's better than nothing.
There are also several initiatives to improve this situation. Google has come with certificate transparency ( http://www.certificate-transparency.org/ ) which essentialy creates public log of all issued certificates so everyone can see and verify that certificates authorities don't issue bogus/fake certificates
There is also an idea to use proof of work to estabilish network-wide consensus about valid certificates (like bitcoin or namecoin blockchain). This would be fully decentralised solution.
Quitte the opposite. They themselves came forward about what happened, communicated clearly and took steps to mitigate the problem. From what I saw, they acted responsibly and it has only I erased my trust in them.
Since you mentioned crappy provider, I would like to add that there is an illusion of choice when it comes to SSL certificates. When I was purchasing an SSL certificate, I researched many and after speaking to the same sales rep on multiple sites, I realized they are all the same company. To quote-
Symantec’s family of dominant SSL brands includes VeriSign, GeoTrust, Thawte, RapidSSL and TC Trust Center.
They own about 70% of the certificates, all priced differently to give you an illusion of choice. So if one provider is crappy, their support is the same; and thus they are all crappy.
> Business validation is optional and doesn't enhance the transport-layer security benefits of using SSL.
Except that SSL isn't just about transport-layer security, it's also about identity. The entire model of SSL breaks down if anyone can buy a certificate for anything.
Except the identity part is well and truly fucked and in serious need of redoing. It relies on trusted CAs, which has been shown is a bad idea, because some of the trusted CAs mismanaged their private keys or have been paid to or been coerced into giving out valid certificates to third parties, permitting them to impersonate websites.
Which browser makes it clear to the user that some unknown organization has "verified" the business hosting the domain they are at? All a user sees is a little lock, no matter what cert you buy.
Where? Changing the color of the lock? That's the whole point, users have absolutely no idea that means anything, they can not differentiate between certs.
I would be willing to bet over 95% of SSL-secured sites don't have business validation certificates. Given virtually nobody visiting your site will know what that means, let alone how to check anything about the certificate you're using, it just doesn't make sense to pay extra for no benefit. A domain-validated certificate costs less while providing the same padlock icon and level of encryption, and takes just minutes to obtain -- pay, paste a CSR, click a link in an e-mail, and you have a cert.
In my case, I don't care about encryption. On my website, I only offer software for download. No private data. Payment is handled by a third party.
The only reason why I want to support https is so that customers can confirm who they are downloading from. Ideally, I'd like an EV certificate, but I can't afford that. So I chose a business validation cert. A domain only certificate wouldn't really confirm anything.
(Also, some of my troubles would have been the same with a domain-only cert. The emails with missing links were those for domain validation, and I had to paste the CSR in the management area that was offline...)
If you offer software to download HTTPS is a must. Otherwise any active attacker, from a kid at a coffee shop to the NSA at the ISPs, can make it so when people download your software they're also downloading your software with malware attached. Software downloads are one of the most important things to protect, and it saddens me that some websites still exist that offer software downloads that don't use HTTPS.
You're really just wasting your time with a "business validated" certificate. The browser doesn't treat it any differently and consumers like my parents would not know the difference or know what to look for. It's all (brilliant) marketing, nothing else. You're equally secure with a PositiveSSL cert from namecheap.com for $8 (or free with a domain registration)..
> You're really just wasting your time with a "business validated" certificate. The browser doesn't treat it any differently
If your vendor doesn't do a decent job verifying who you are (and this may or may not mean EV), then browsers won't treat the certificate any differently when it's entirely replaced by someone else either.
It doesn't matter how good a job your vendor does, if there is a vendor that does a bad job, then the attacker can get a cert from them. The presence of a single bad cert authority renders all certificates useless.
Sorry, but you are still wasting your money on a business validation certificate. A domain validation certificate is the only thing that a browser actually validates and ensures the security between you and the website. The rest is just sprinkles on top to make people feel better and to charge website owners extra money.
The sprinkles are for people buying certs, not the customers of the people buying certs. End users don't even know he got a different cert, or what that means.
If you're willing to write off users of Internet Explorer on Windows XP, you don't need a dedicated IP for SSL; you can simply use Server Name Indication (SNI).
Actually it is, because you'd still have a domain pointed to an IP address listening on 443, and that IP address wouldn't know how to handle the domain that is not configured to listen on 443, so it would serve the default domain (generally the first SSL-configured domain with Apache, or 'default_server' on Nginx). This means you'll be serving a certificate for your default site 'foo.com' when you requested 'bar.org', providing the user with a domain mismatch security warning.
The second non-solution would be to configure every domain with self-signed certificates, but then you'd still be sending your clients an untrusted certificate. The only way to truly provide SSL on a shared host is to configure it with a UCC certificate that includes every domain you are pointing at it, or generate cheap/free certificates like StartSSL's for every unique domain and subdomain you listen for.
Why does that matter if bar.org doesn't and isn't supposed to support HTTPS, and if there are no links to bar.org via HTTPS? In either scenario if someone manually types in https:// bar.org it's not going to work.
I don't think it's at all obvious or universally true that it's better to get an 'Unable to connect' error message than a certificate warning (btw, the default site could tell the user they arrived there by accident should they continue past the warning). Depends on the context.
I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.
People wouldn't be connecting to the website using HTTPS if it didn't have a certificate in the first place, so why does it matter if 'bar.org' doesn't have a certificate?
Nope, just find a CA that will give you a certificate with SAN extensions at a cost that you can afford. Usually you can get up to 5 SANs at a reasonable cost, and up to 100-150 SANs for more dollars.
I had a similar experience when I purchased a software signing certificate from Comodo, exacerbated by the fact that we had accidentally transposed two adjacent digits in the phone number we gave in our listing. It ended up taking about two weeks in all to get Dun & Bradstreet to correct the typo and have Comodo verify the update, and then call us at that number. While the delay was not pleasant, I am glad that they make an effort to ensure that a legitimate organization is purchasing the certificate.
They just resell Comodo certificates, so I assume I'd have the same issues with broken emails and offline managment area and emails promising "Your order is being processed right now" (the business validation stuff was only a part of the problem)
Also, it makes me angry how you have all those beautifully designed landing pages everywhere, and as soon as you have ordered, you have to deal with ugly and confusing websites that barely work at all.
First of all, I had to get a dedicated server, because a bunch of other sites were running on the same server, and the hosting company doesn't offer additional IP addresses.
Then I wanted to get an SSL certificate. I picked Comodo, because they seemed to offer the cheapest full business validation certificate, but then accidentally bought a domain only certificate because their marketing was so confusing. Their friendly customer service walked me through a complicated process for changing my order.
To get the certificate issued, it took me a week to collect the documents they requested. I had to make sure my business was listed in the yellow pages, so they could send me an automatic phone call for verifying my number.
After every step in the process, they told me to log into their online management area, which was offline from time to time.
I had to confirm my email address by clicking a link about a dozen times. Half of the emails were missing the confirmation link.
Twice I got an email telling me my order will soon be processed, and nothing happened for two days. I had to open tickets in some online support area or send them emails to get them to continue processing.
All in all it took me a month to get SSL working. Now I understand why so many sites do not use HTTPS.