Hacker News Reader

I agree, for two reasons:

1) Let's Encrypt are based in the United States and are already forbidden from issuing domains to certain people[0] due to US law.

2) Having a separate production implementation of an ACME-compliant system would help make sure that the protocol is as robust as it can be

[0] Notably Iran and Syria - several certificates issued for gov.[ir|sy] had to be revoked after they slipped past their blocklist: https://community.letsencrypt.org/t/blocklist-incident-novem...

Just to be clear, Let's Encrypt does issue for non-governmental entities in U.S.-sanctioned countries (which some other U.S.-based CAs don't do).

https://crt.sh/?Identity=%25.sy&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418

LE arose from a EFF/Mozilla effort to get encryption everywhere, an aim that obviously is close to the EFFs mission.

What would be the motivation for a competitor?

Wildcard certificates, long-life server certs, and signed client certificates. There's a lot of other stuff that LE doesn't handle, too.

I don't think 'competitor' is the right word here -- maybe 'second basket so all our eggs aren't in one'.

I agree with the eggs/basket argument, though I suppose there's an argument to be made about a number of CAs being essentially too big to fail already, so what's one more?

Regarding client certificates: There aren't really many good reasons to use publicly-trusted certificates for client authentication, but if you insist, you can use Let's Encrypt for that. The certificates do have the id-kp-ClientAuth EKU.

I think it would be nice to move toward having a lot of medium-sized nonprofit CAs instead of a handful of crappy commercial ones, which is the current situation.

"Too big to fail" is the problem with the current CA system, and today's well-run TBTFCA is tomorrow's global security crisis.

When I think "mission critical audited security practices", non-profits don't exactly come to mind.

Oh, but Comodo does? Good luck.

A small sample does not generalize to a trend.

OMG yes on wildcard certs! My company has multiple domains and uses subdomains for every affiliate and we have thousands of affiliates. One *.example.com cert per domain and we're good to go. Now if only we could get IIS to support multi-domain wildcard certs so we could get all of our domains and subdomains under one master cert I'd be in heaven! (SNI doesn't work for us b/c ~12% of our traffic still uses IE7 or earlier).

So why not buy one now? I get the excitement about simple certification process, free access and refresh, etc. But if you have thousands of affiliates, current wildcard cert providers should offer a pretty good solution. Is anything missing there? I mean, if we ignore the idea why LE is good in general, $100 / year is nothing if you actually need a wildcard.

Oh we absolutely do just buy them now through RapidSSL. It's all of those other reasons I wish LE supported them. I wouldn't mind paying LE for them, I want an API for requesting them, a simpler certification process, and easier refreshes.

I don't get the desire for longer-life certs. I would argue that they should be shorter to keep the exposure of a leaked cert down. Whether a cert is good for a week or a year you should be automating the renewal.

basically no 3rd party system is designed to execute programs to obtain new certs when they expire. so can't use LE for existing workflows.

Why do any non-profits pop up?

Obviously LE employs a handful of people, and they are in some ways an "advertisement" for Mozilla (not that it's a bad thing). Those alone are some reasons why something might want to be attempted.

But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.

Think something like a domain host providing certificates themselves (which IMO makes a hell of a lot of sense).

CloudFlare creates certs as part of its service.

> But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.

This is what I expect we'll see more of, rather than a second (and perhaps slightly different) Let's Encrypt. Major cloud providers will probably add their own variants of what Amazon offers with AWS Certificate Manager (ACM); more CDNs will start offering one-click SSL (like Cloudflare); "traditional" web hosting providers and control panel vendors will (hopefully) support SSL by default (like cPanel with AutoSSL, which supports Comodo and Let's Encrypt).

Yeah, and I'm also hoping they will gravitate toward more "standard" interfaces like you touched on at the end there.

With the help of Let's Encrypt and through some cooperation, we could make easily "pluggable" SSL cert providers where you can choose who you want with the click of a button.

I think it's fairly likely we'll see a number of CAs adding ACME support at some point. Judging by participation on the ACME mailing list, there seems to be interest from (at the very least) DigiCert, Entrust and cough StartSSL. I guess most of them will want to wait for the standardization process to finish before announcing any plans.

Same as EFF/Mozilla. Let's Encrypt hasn't fulfilled their goal until everyone can get free HTTP encryption.

As a user, if I have to wait 24 hours (or more, depending on queue depth) for a Let's Encrypt batch queue to be processed after I sign up for some free blogging platform before I can use an assigned subdomain, then I'm probably going to close my tab and never come back. Let's Encrypt hasn't fulfilled its goal until this doesn't happen any more. This batch queuing model is necessary so that sites don't exceed the Let's Encrypt daily quota.

Some applications rely on wildcard subdomains, and require a wildcard certificate to be instantly responsive.

To anyone thinking "just don't use encryption until after the cert has been provisioned"—not going to work if you use HSTS. Your users have to wait all day before they can use their subdomain.

This sounds more like a design decision by that blogging platform rather than something that's caused by Let's Encrypt. Excluding maintenance windows or any other unplanned downtime or performance issues (which happen relatively rarely), the issuance process doesn't take anywhere near close to 24 hours. Account registration, domain validation and certificate issuance is typically done in less than ten seconds.

The existing rate limits[1] should have very little effect even for very large integrators. A form for rate limit adjustments exists for those who need a large number of subdomains (and would rather not obtain a wildcard certificate) or need to add new domains at a very high rate (i.e. the WordPress.com's and OVH's of this world).

[1]: https://letsencrypt.org/docs/rate-limits/

Edit: The document you linked to was recently updated, but the top of the page incorrectly says "Last updated: August 10, 2016". I wrote my response with the old document in mind. It's obvious to me now that this page was actually last updated in December 2016.

If I don't batch multiple SANs into one certificate and stagger a certificate queue, I will very quickly run into the Let's Encrypt rate limit.

If I don't want my users to wait for the queue to be processed, I could immediately request a new certificate for every new user's subdomain, but then I'd be limited to 10 new users every 3 hours.

I assume by "multiple SANs", you're referring to subdomains under the same registered domain? In that case, you can use the rate limit adjustment form or register your domain as a public suffix if that's more appropriate. The form has been available since August. The rate limits in general have not changed since back then (or even before, I don't recall) either.

> LE has saved us from spending many man hours of time updating certificates

Just out of interest, how are you managing the 90-day renewal schedule? Don't you need some means of verifying that timely renewal has occurred.

Since you mention dev and staging I assume you've implemented a central certificate-management server that talks with LE and then issues the certs to the internal machines?

Presumably, you would want to have monitoring in place for certificate expiration either way, so this expense is not really specific to short-lived certificates.

Use cert bot to auto renew https://certbot.eff.org/docs/using.html#renewing-certificate...

Also include command like below as part of your automated audit scripts:

echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates

http://www.shellhacks.com/en/HowTo-Check-SSL-Certificate-Exp...

FYI, you can simplify that to

openssl s_client -connect google.com:443 </dev/null 2>&1 | openssl x509 -noout -enddate

No, we tend to keep our staging and dev servers public-facing for the most part. We do a lot of remote work, and it's easier that way.

Everything is kept behind our application authentication, and they almost never have "real data" on them so it's not really an issue for us. And having the certs on the dev machines just makes setting up and testing with HTTPS that much easier and it's a no-brainer with LE (plus it lets us ensure that everything there is working correctly, and gives us fully authenticated HTTPS connections with our dev servers!)

In the rare event that we need a dev server and can't put it behind our application auth, it's generally locked to localhost and we use SSH forwarding until it can be.

As for managing the lifetimes, we just use certbot the same as we do for the production machines, similar to the way the other commenter pointed out. And I believe one of our guys has some alerts setup for monitoring the expiration of the certs and warning if it gets too close to expiring, but I don't really know anything about how that works.

> Just out of interest, how are you managing the 90-day renewal schedule?

Not the parent, but I use certbot running monthly with a cron job. It skips any domains that aren't up for renewal, and renews domains when they are close to expiry.

I then get a monthly email telling me which domains were updated and which ones were skipped.

It's completely painless. 90-day renewal isn't a problem when the whole process is completely automated.

I would (and do) run it weekly.

If it runs monthly, and one of your renewals fails (i.e. transient network error), your certificate may expire before it next gets the opportunity to renew it.

And then I get an email from cron telling me it failed, and I log in and run certbot manually.

I don't run enough sites that this is a problem.

StartCom (the name behind StartSSL launched StartAPI/StartPKI in May. I would call it a direct competitor to LetsEncrypt.

Given the recent events regarding them and their parent company, I'd be wary of using them for anything at this point.

Even if you wanted to, you can't really use them right now. Mozilla, Google, and Apple untrusted their (recently issued) certs.

That's what StartCom might thought when they announced their new service "Start Encrypt" around the same time when Comodo tried to get hold of the "Let's Encrypt" trademark which Let's Encrypt successfully fought back.[0] Then some more deserved buckets of shit hit their fan. I can't bring myself to call StartCom a competitor of Let's Encrypt.

[0] https://news.ycombinator.com/item?id=11961034