Hacker News Reader

Comment by achille | Hacker News Reader

How dare they give you a free service, and then decide to charge for a revocation which they had said they would charge for (and is meaningless because by default all browsers ignore revocations).

Unfortunately for various historical fuckups, we consider self signed certificates to be more dangerous than cleartext unsecured http. Lots of scary warnings pop up. That is absurd. Starcom is helping fix this by issuing free certificates.

The Mozilla CA policy does not include a provision for obvious trolling and posturing. If Starcom were to be forced to revoke your certificate for free, why would anyone else (on any CA) ever pay for revocation?

View on HN

> (and is meaningless because by default all browsers ignore revocations)

Strange, because when I revoked my cert at StartSSL yesterday (and payed for it), the browser, Firefox on Ununtu immediately showed it as revoked. With a big bold warning when visiting the page.

> The Mozilla CA policy does not include a provision for obvious trolling and posturing. If Starcom were to be forced to revoke your certificate for free, why would anyone else (on any CA) ever pay for revocation?

This is not your garden variety, "I screwed up my .htaccess file and accidentally leaked my private key to the world" situation. This is a special case, and some special case rules would be really appreciated by this one, at least.

> The Mozilla CA policy does not include a provision for obvious trolling and posturing.

This isn't really trolling, after Heartbleed we should consider all SSL certs used by OpenSSL based servers as compromised. This sites just tries to make the point more obvious by putting such compromised cert in public view.

Have you realized that not only OpenSSL, but any exploitable bug in any software that runs on servers (PHP, Apache, nginx, Linux, etc) should theoretically invalidate any certificate that is stored on those servers?

Any exploitable bug that allows to access private keys should invalidate certificates. There are many security vulnerabilities that don't give access to private keys.

Even if there's no publically-known way of using a particular security vulnerability to get access to private keys, how are we to be sure that somebody (perhaps malicious) didn't find a way and are just keeping it a secret?

If you understand a vulnerability, you can often tell for sure if it can lead to exposure of private keys. For example if a PHP app runs in a separate process with separate user credentials than nginx SSL endpoint, and if file access control flags for certificates are configured correctly, you can tell for sure that php bug alone won't allow for certificates access. This of course assumes that other components work correctly (like Linux access control mechanism), but without such assumptions you wouldn't be able to do anything productive.

I'm also against bashing of StartSSL but they could at least show some good will.

"I'm not angry, I'm just disappointed"

Nothing wrong with bashing a free product or service.

If I paint two pieces of art, one I let you view for free, the other I charge to view - are you only entitled to an opinion on the latter?

I thought this post was simply making clear on an example domain what the policy was, and that because of the heartbleed issue, the author had legitimate concerns about the other certs' security. This one was just posted more obviously to prove the point.

Reply on news.ycombinator.com