4 ms·

It sounds like everything is running fantastically for them, and I'm really glad. LE has saved us from spending many man hours of time updating certificates ac

It sounds like everything is running fantastically for them, and I'm really glad. LE has saved us from spending many man hours of time updating certificates across all dev, staging, and live machines across all of our servers every year (which just so happens to be almost exactly the amount of time needed to forget some of the details of what needs to be done...). But all that being said, when are we going to see a competitor pop up? Clearly what they are doing is working, so when are we gonna see some others attempt to do this? Having all your eggs in one basket is never a good thing in any part of life (no matter how perfect that basket is). Having more than one "Let' Encrypt" would at the very least spread out some of the risk, and might even enable them to specialize a bit more (perhaps the competitor could target the issue of wildcard certs, or be somehow tailored for the use case of needing thousands of subdomains). Has there been anyone else trying this?

M2Ys4U 10y ago
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-november-21-2016/23008 https://community.letsencrypt.org/t/blocklist-incident-novem...
- schoen 10y ago
  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.sy&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418
mhurron 10y ago
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?
- stonogo 10y ago
  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'.
  - pilom 10y ago
    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).
    - viraptor 10y ago
      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.
      - pilom 10y ago
        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.
  - pfg 10y ago
trey-jones 10y ago
StartCom (the name behind StartSSL launched StartAPI/StartPKI in May. I would call it a direct competitor to LetsEncrypt.
- __david__ 10y ago
  Given the recent events regarding them and their parent company, I'd be wary of using them for anything at this point.
  - Ded7xSEoPKYNsDd 10y ago
    Even if you wanted to, you can't really use them right now. Mozilla, Google, and Apple untrusted their (recently issued) certs.
- schlowmo 10y ago
  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 https://news.ycombinator.com/item?id=11961034
dingaling 10y ago
> 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?
- pfg 10y ago
  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.
- esterly 10y ago
  Use cert bot to auto renew https://certbot.eff.org/docs/using.html#renewing-certificates 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-Expiration-Date-from-the-Linux-Shell http://www.shellhacks.com/en/HowTo-Check-SSL-Certificate-Exp...
  - aaronmdjones 10y ago
    FYI, you can simplify that to openssl s_client -connect google.com:443 </dev/null 2>&1 | openssl x509 -noout -enddate
- Klathmon 10y ago
  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.

M2Ys4U 10y ago

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-november-21-2016/23008 https://community.letsencrypt.org/t/blocklist-incident-novem...

schoen 10y ago
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.sy&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418

mhurron 10y ago

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?

stonogo 10y ago
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'.
- pilom 10y ago
  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).
  - viraptor 10y ago
    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.
    - pilom 10y ago
      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.
- pfg 10y ago

trey-jones 10y ago

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

__david__ 10y ago
Given the recent events regarding them and their parent company, I'd be wary of using them for anything at this point.
- Ded7xSEoPKYNsDd 10y ago
  Even if you wanted to, you can't really use them right now. Mozilla, Google, and Apple untrusted their (recently issued) certs.
schlowmo 10y ago
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 https://news.ycombinator.com/item?id=11961034

dingaling 10y ago

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

pfg 10y ago
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.
esterly 10y ago
Use cert bot to auto renew https://certbot.eff.org/docs/using.html#renewing-certificates 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-Expiration-Date-from-the-Linux-Shell http://www.shellhacks.com/en/HowTo-Check-SSL-Certificate-Exp...
- aaronmdjones 10y ago
  FYI, you can simplify that to openssl s_client -connect google.com:443 </dev/null 2>&1 | openssl x509 -noout -enddate
Klathmon 10y ago
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.