Hacker News Reader

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.

> I've always heard and read otherwise.

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.

http://www.theroiteam.com/blog/is-an-ev-ssl-worth-it-or-even...

http://webmasters.stackexchange.com/questions/7697/ev-ssl-ce...

http://forum.x-cart.com/showthread.php?t=54707

http://www.quora.com/VeriSign/Does-ecommerce-conversion-incr...

The first link mentions EV certificate handshake is slower. Is that really the case? What is the reason?

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.

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.

Considering Amazon.com doesn't bother with an EV cert, I'd guess they don't affect conversions in any sort of positive manner.

Amazon also says that Settlers of Catan is the number one selling children's musical instrument toy. They don't do everything 100% right.

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

Yes, it's HTTPS, but it's not EV HTTPS. There's no green bar, just the lock icon that anyone with a $7/year SSL gets.

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.

> It's been studied

Got any source? Would really like to show that to some folks here ...

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.

> 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.

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.

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.

That's "increased", yeah?

> The CA system is totally flawed anyway

The flaw basically being that people aren't trustworthy, yes?

Do you have any alternatives? There's ssh's model, where you just hope it's the right certificate the first time; or maybe mob-source it like WoT?

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.

I like the idea of a blockchain for it, the only downside would be using all that space.

I didn't know about that incident. Thanks for pointing it out. Here are some references:

https://www.schneier.com/blog/archives/2011/03/comodo_group_...

https://kb.bluecoat.com/index?page=content&id=SA54&actp=RSS

> 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.

EV Certs show the company identity, which has been verified. Go to paypal for an example.

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.

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.

I use DigiCert at work, and have been very happy with their support, however they are not cheap.

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...)

Some if not all payment processing websites, like Stripe, still require that you use SSL to prevent MITM attacks.

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.

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.

>> so that customers can confirm who they are downloading from

This would seem that he was in fact looking to provide "some sprinkles [to] make his customers feel better."

Perhaps not a waste of money, then, if it provided what he was looking for?

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.

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.

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).

Android 2.x also doesn't support SNI.

Android 2.x is rapidly becoming the new "Windows XP".

But then I'd need to support SSL for all domains hosted on the server, and this would mean getting 5 certificates instead of one.

That's not true. Why do you think that?

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.

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?

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.

You'd need at most two IP addresses to resolve this problem: one for HTTP/HTTPS sites, and one for HTTP-only sites.

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.

If you just want the security of SSL, don't bother with the EV certificate. It's hugely easier.

You could have just bought the $7 cert from getssl.me and it would take 2 minutes at most.

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.

You only receive a validation email from Comodo if you use their services.