Hacker News Reader

Comment by 0xmohit | Hacker News Reader

It's about time that HN switches to Let's Encrypt.

The processes for handling LE cert renewals is quite different than for traditional certs with manual trusted-operator procedures.

It's a lot more work to switch an existing cert environment to LE than to start from zero.

Why? Is there something wrong with HN's current cert?

Suffices to say that it has been issued by Comodo.

1. Funds Comodo's shady behaviour, and arguably increases their brand recognition

2. Ridiculous expiry time

> Ridiculous expiry time

Looks like a cert is similar to a President. Should be around for 5 years.

You know that Comodo won't issue a refund if they decide not to use them any more right? They've paid the money.

I can understand moving things to show support for better alternatives but let's not kid ourselves - moving now or moving when the cert expires, doesn't hurt Comodo any differently.

It appears that HN's cert is a wildcard, so they can't switch yet anyway.

Does it need to stay that way? I'd assume there are only a couple of subdomains (www, news, maybe a handful more?), so replacing them with SANs or separate certificates shouldn't be too much work.

Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal.

> Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal.

Say what? Besides the faux security of the green bar for an EV cert, what's the difference between a LetsEncrypt and a paid one? (non-EV)

Heads up: I work for a company that speeds up the background checks used for EV.

Tying real world identities to public keys is very much a part of crypto. Windows does it with package signing and EV, Debian does it with people holding up their passports at Linux events, and web sites do it with EV HTTPS.

And yes, we (CertSimple) are looking at Certbot support for EV.

FYI: Your server's vulnerable to CVE-2016-2107 and is getting an F from ssllabs.

https://www.ssllabs.com/ssltest/analyze.html?d=certsimple.co...

Lol

Now back to our previous A+. Thanks for the heads up.

I had been logging in to update but the rate of new, severe openssl vulnerabilities - and the risk of missing one, fairly obviously - is high enough I'd rather just apply them immediately. yum-cron's also now enabled to apply openssl updates as soon as they're issued.

> Heads up: I work for a company that speeds up the background checks used for EV.

How much faster? The one time I've gotten an EV cert it took a couple hours to get verified. Didn't seem too long at all and compared to the time to plan the swap out of the cert in production, the wait was a non issue.

The verification itself was a joke though. It was basically just a phone call asking "Are you X? Ok great! Here's your cert!"

> Tying real world identities to public keys is very much a part of crypto.

Joe User isn't going to look at the details and validation chain of a certificate. The whole idea of the green bar for "more trusted" is a scamola by the cert providers as they saw the writing on the wall for their margins going to zero for domain validated ones (granted they saw it early enough to get traction on it!).

> How much faster?

https://certsimple.com/about

> The verification was basically just a phone call asking "Are you X? Ok great! Here's your cert!"

Congratulations, you have an active registered company that was already well known to qualified third parties. Before that phone call happens, the CA has to verify your existence and status by government records and a qualified third party. There are additional steps for certain company structures. They don't just call you and you get the cert - and people are often rejected.

> Joe User isn't going to look at the details and validation chain of a certificate.

Nobody is expecting users to look at the cert details or verification chain. Just the name in middle of the address bar.

From the front page of HN right now:

https://hackernoon.com/this-is-what-apple-should-tell-you-wh...

https://d262ilb51hltx0.cloudfront.net/max/800/1*DzlpfS4cesC6...

"The green text on the address bar shows the site really belongs to Apple Inc."

> Tying real world identities to public keys is very much a part of crypto. Windows does it with package signing and EV, Debian does it with people holding up their passports at Linux events, and web sites do it with EV HTTPS.

This would be a legit argument if EV HTTPS actually achieved that goal. They don't, though: the identity verification around EV HTTPS is a joke.

Can you elaborate?

The identity verification is essentially a phone call for most CAs, which verifies nothing. Some CAs do better, but it only takes a few bad apples, and in this case it's not a few bad apples--it's mostly bad apples.

Before that phone calls happens a bunch of other work has to be happen first - see the other answer for details.

All CAs are audited against the same guidelines: they should be requiring the same levels of proof. From what I've seen (our tech works with different EV providers) that's generally the case.

While EV is certainly more than a phone call, there are certainly flaws. The EV guidelines change over time and I'd like to get them tightened with additional requirements in particular circumstances.

One of them is tied to a root CA and works on all devices. The other is not, and does not.

LE is tied to a root CA (IdenTrust's). The support is almost universal, with only obsolete OSs not trusting them: https://community.letsencrypt.org/t/which-browsers-and-opera...

Lot's of people care about and make their money off users with "obsolete OS's and browsers".

And they're just as likely to have problems with any other CA.

Including HN / ycombinator?

Despite a fairly large number of users on XP still (2.5% of total users on some sites I manage), I'll give you that it works on non-obsolete OS browsers. However, those are not the only pieces in the world of security.

Java, for example, only started support as recently as 3 weeks ago (2016-07-19)

XP is supported. There was an issue due to some schannel bug in XP choking on the issuer certificate, but that was fixed earlier this year.

Certificates issued by Let's Encrypt are cross-signed by IdenTrust and are trusted by all major browsers[1]. This is just about their own root certificate. Being cross-signed by an existing, trusted CA is a common practice for new CAs, as it would take years for the CA to become usable in practice otherwise.

[1]: https://community.letsencrypt.org/t/which-browsers-and-opera...

Wildcards.

compatibility, at least in the short term?

I put a LE cert on a project, and some folks calling the API with old Java clients couldn't trust the cert. They could have upgraded, but it was easier to get a commercial cert and be done with it.

Reply on news.ycombinator.com