Hacker News Reader

Comment by Someone1234 | Hacker News Reader

This is going to sound super ungrateful but...

If they already have the CA stuff ready can they just release that? I don't really care about their auto-magical tool which is meant to reconfigure your server for you. Configuring Apache/IIS etc is not that complex, the only reason I don't have a certificate on my private website is because the certificate costs more than the hosting annually (literally).

Plus I'm never going to run this tool even when it is production ready. I don't trust random tools to reconfigure my system, and would prefer to manually follow tutorials so it is easy to undo every change or at least be aware of exactly what changes got made.

View on HN

The CA itself is not ready yet. When it is, you can use the client in a simple mode to grab a certificate and drop it wherever you want, without automated configuration.

I don't want a tool that I have to run as root and that is going to touch anything in /etc/nginx/.

I do want a tool using which I can do something like:

    $ letsencrypt 'foo.bar.example.com'

which would spit out foo.bar.example.com.key, foo.bar.example.com.cert, and foo.bar.example.com.csr.

I'd also like to have:

    $ letsencrypt --renew foo.bar.example.com

Which would re-generate all these certs. The main problem for me, just like for you, is that domain validation certs are not free (or at least somehow included in the price of the domain registration). This type of tool solves that.

If, on top of this tool, we also get something that lets a person new to ops autogenerate or even autodeploy an nginx vhost with TLS/SPDY support, awesome! But the ability to generate and renew certs from the command line, for free, is what I want and probably what you want too.

Being able to run the tool as non-root so it just spits out the key/cert pair is EXACTLY one of the mode of operations that they said will be available - see http://media.ccc.de/browse/congress/2014/31c3_-_6397_-_en_-_...

I totally agree. You would however need to somehow authenticate that you own foo.bar.example.com (code in email, host something under foo.bar.example.com, a TXT record, etc.).

The tool shouldn't need root access to /etc/nfinx (or whatever your config Dir of choice is) to authenticate your ownership of a domain.

The tool doesn't care about your ownership of the domain, it cares about whether the host it's running on is trusted by the owner of the domain. The simplest way to verify that is for the CA to tell the tool "serve up this nonce value at this randomly-generated URL", and then to request that URL and see if it gets the right value.

Depending on exactly what proof the CA wants, that will probably require some kind of tinkering with the webserver's config, or at least inspecting it to figure out how to fulfil the CA's request.

Hopefully there'll be a fallback mechanism that tells the sysad what to configure, if only because not every webserver in the world is Apache or nginx.

Unless the tool includes a server that can do this all on an alternative port.

They explicitly want to test 443.

Or, we could just let registrars issue these certs.

Problem solved.

They were never going to for free - the ones that do sell certs make huge amounts of money off them. That's why LetsEncrypt exists - to push the market value of a trusted X.509 certificate close to 0.

> Plus I'm never going to run this tool even when it is production ready. I don't trust random tools to reconfigure my system, and would prefer to manually follow tutorials so it is easy to undo every change or at least be aware of exactly what changes got made.

Agreed. I can already generate and install a certificate (though I wouldn't mind a standalone tool to make that simpler). I'd like some automated process that renews that certificate, or better yet, certificates that don't expire in the first place.

I'd be happy with automated renewal. Certificates that don't expire seems like a bad idea.

It makes sense for certificates to expire when domains do (though domain expiry also seems like a bug), but other than that, I think every other use case for expiry is better served by revocation.

What if you can't connect to the internet to check? Expiry works better in a lot of other cases, including offline systems with intranet-only access. Without expiry, you can DDoS a revocation server and perform an MiTM with a very weak cert issued 20 years ago (supposing the client accepts it.)

Intranet systems, and those connecting thereto ( e.g. corporate VPN clients ) should really be using only a trusted internal CA with mutual server- client authentication. Probably with hard coded cert signature on each end.

For example on our network every user-laptop-service combination has a unique cert. A user can be dropped from, say, accessing IMAP with a single change on the server and without affecting their webmail access.

MITM is very difficult in that scenario as the attacker had to compromise both ends.

Half of the point of expiry is to ensure that practices that used to be secure and are now not safely reach EOL, hence the 39 month restriction soon in place.

Without the expiration parameter, you could crack an 512 or 1024 bit certificate five years from now and it would be just fine to use. All you would have to do would be attack the CRL/OCSP server and keep it offline for a very short period of time.

There are several systems for servers to provide "stapled" indications from a CA that a certificate has not been revoked as of a given date. And if you're accessing an offline system on an Intranet, you might want to use a pinned certificate, or a pinned internal CA.

Revocation is a much harder problem than the rest of the world wide PKI put together.

With a short enough expiry, you might not even need revocation. (See: DNSSEC.)

> If they already have the CA stuff ready can they just release that?

While I'm sure they have something ready[0], I'm not sure they have a fully-worked-out policy for running it (required to get into certificate chains), or a production deployment of it, or a third-party vulnerability test of it.

Additionally, ACME verification is a vaguely complicated protocol which will likely need a tool to sign the various messages involved (or you're going to be looking at munging together OpenSSL commands), and you're looking at the developer preview of that.

[0] https://github.com/letsencrypt/boulder

> because the certificate costs more than the hosting annually (literally).

So what you are saying is that because you can get an SSL cert free from startcom, that your hosting provider is paying you?

https://www.startssl.com/?app=1

I don't think anyone is home:

https://forum.startcom.org/viewforum.php?f=8

After I saw the state of their forums/community I ran, not walked, away from their service. Which is rather scary considering they are a trusted CA...

I think really the only reasonable thing to do is pay $15/yr for any site that other people will use and use your own CA for your personal projects.

Getting CA certs into Android however is whole other issue...

Good god. I knew StartSSL was bad, but not this bad.

I usually buy certs either through Gandi.net (which has a good "free certificate" program with its own domains), or COMODO through Namecheap as a reseller.

StartSSL's free cert don't support wildcards and the revocation of a cert is $25 per, which can be a problem (it was during Heartbleed).

I understand they also have a pretty bad interface and terrible customer service.

What would you expect if you are not paying for the cert? For me revocation was not an issue. I just got a new cert under a different subdomain as I don't use subdomains on my personal site and the main domain is added as an alt name.

What I would expect is for every CA to comply with the CAB/Forum Baseline Requirements, § 10.2.4:

>If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

There is no "if you pay them" condition to that. CAs are not supposed to make, or allow to stand, any signature on a compromised key—period.

Startcom's refusal to revoke all compromised public keys communicated to them after Heartbleed, and in fact their practice of charging for any revocation in general, is not in compliance with the baseline requirements for a CA.

As a result, Startcom should be removed from all browsers as a trusted CA. Let's Encrypt would be a very good replacement, especially if they also offer keys using ECC P-256 (and perhaps a subsequent replacement ECC algorithm).

Interesting case. This seems to contradict their own CPS as well, 4.1.9:

> A certificate will be revoked when the information it contains is suspected to be incorrect or compromised.

and

> The subscriber’s key is suspected to be compromised;

>The technical content or format of the certificate presents an unacceptable risk;

There was never any conformation that all/most/any startcom used/issued keys/certs were leaked so they were never under any obligation really.

That's not a correct response to Heartbleed... It could have been easily exploited to get your private key and certificate, and not revoking it leaves it valid.

I don't "expect" anything, I'm giving reasons why startssl might not be an option.

It's quite reasonable pricing. It's less than most CAs does for a one year certificate, and revoking it is more work than issuing it in the first place.

They are not without fault, but they've much good for open source project and the like, and don't deserve the bad rap thrown at them in every thread that mentions SSL.

There was no bad rap in the thread until btreecat decided to be an ass. The only other subthread mentioning startssl is https://news.ycombinator.com/item?id=8904105 which only notes that as far as he can see letsencrypt is similar to startssl's delivery/validation process and seems to be vulnerable to mitm.

No need for rude personal attacks thank you.

"Free" if you don't count your time spent dealing with their terrible interface...

And also, you'll need IP addresses for each subdomains hosted, which can rack up costs. Though most of "modern" browsers and OS support SNI, this is less of a problem now.

False. I was able to get two certs issued for different sub domains for free. This was how I got around them charging $25 for revocation during heartbleed. I use the alt name in the certs as is.

I meant for hosting providers. If you are on any type of a hosting provider that doesn't have dedicated IP assigned to them, such as in case of "shared" hosting. If the service support SNI (Server Name Indication) then dedicated IP is not necessary, only complication is that if your site needs to support older browsers and/or OS, SNI may not work.

StartCom (or any of CA) doesn't care about IP address.

Reply on news.ycombinator.com