4 ms·
I think Let's Encrypt is great and their certbot tool makes it even better. With Wildcard certificates coming to Let's Encrypt, I think they will only increase
by 013 9y ago
I think Let's Encrypt is great and their certbot tool makes it even better.
With Wildcard certificates coming to Let's Encrypt, I think they will only increase in users. (https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...)
- osrec 9y agoAgree with this - it's one of the few missing features of lets encrypt. I think more SaaS websites will be inclined to use the service, especially ones that have user.saas.com subdomain structure.
- frik 9y agoHow about distributing Let's Encrypt? Do cloud hoster offer a copy of the service from their datacenter? Otherwise it could be a single point of failure / single attack vector, right?
- pjc50 9y agoDistributing a CA makes it less secure, not more; ultimately the thing that "is" a CA is the private key, which ought to be stored in a HSM and never let out.
- sova 9y agoMirroring Certificate Authorities seems to create more potential security holes...
- stephenr 9y agoTheir infrastructure is meant to all be HA from memory, and unless you're doing stupid things like caddy did[1] small windows of downtime shouldn't cause much issue for ongoing operations anyway - you will likely be starting to attempt renewing certs weeks before they expire. 1: https://github.com/mholt/caddy/issues/1680 https://github.com/mholt/caddy/issues/1680
- hkeide 9y agoWow, that Caddy thing is pretty scary, thanks for pointing it out. I wonder what other decisions like that lurk under the surface.
- frik 9y agoI meant a clone/copy of the (hopefully open) server software of LetsEncrypt stack running as a service on several well known cloud datacenters - of course under a different name. Why? Not a single point of issue. Given now that it has now 25% market share, it's a high profile target, and given he short cert lifetime aggressive updating is necessary meaning you could receive a underhanded cert in case someone gets access to the high profile target. If Let's Encrypt is not a startup and doesn't plan to make money, then there should be no problem to release the whole service as DEB/package so that every big hosted can run a clone under a different name. Or is LetsEncrypt in the business of gathering analytics and selling the usage data? I think no.
- pfg 9y agoJust to clarify, do you want to give every one of those big hosters the keys to the internet, as in either a new root CA or one that's cross-signed by an existing CA? If you're not giving them that, I'm not sure what they would do with just the CA server (which is indeed open source, by the way.) If you're giving them the keys ... well, do you really want to trust every single big hoster with the keys to the internet? They would still have to pass (very expensive) audits, apply for root inclusion, etc., so it wouldn't be as simple as running the Let's Encrypt server stack. Amazon and Google run their own independent CAs already, with Amazon offering free issuance as part of some of their products (with non-extractable keys). I'd expect Google to offer something similar in the near future. I'm reasonably confident that these companies know how to run a CA, but I'm not sure I would trust many other hosters with something like that.
- dijit 9y agoI'm quite sad that they're doing the wildcard thing. There are RFCs stating the problems they cause[0]. It would have been nice to steer people away from this awful security practice. I wrote a very opinionated and ranty blog post which goes into more detail ( but strongly implies people lazy :( ) https://blog.dijit.sh/please-stop-advocating-wildcard-certificates https://blog.dijit.sh/please-stop-advocating-wildcard-certif... [0]: https://tools.ietf.org/html/rfc6125#section-7.2 https://tools.ietf.org/html/rfc6125#section-7.2
- lclarkmichalek 9y ago> In my opinion if you’re lazy enough to warrant a wildcard cert then you’re too lazy to do security properly anyway, period. You don't present yourself in a way conductive to convincing anyone of anything.
- dijit 9y agoRegardless of the format; the statement still stands, even if it's overly combative. There is functionally no requirement for wildcard SSL that can't be met another way- the other ways in almost all cases are better for user security. Not designing for it (just like not designing for cloud failure) isn't someone being belligerent about nothing it really only emerges out of laziness or unwillingness. (or, you have a legacy application which is architected a certain way, which is similar in my scenario of having a "non-cloud ready" application.. it's not a good reason to architect things in future this way)
- dijit 9y agoI wrote a less combative follow up: https://blog.dijit.sh/follow-up-wildcard-tls-certificates https://blog.dijit.sh/follow-up-wildcard-tls-certificates
- troyjfarrell 9y agoDo you have an opinion on Sandstorm's use of wildcard certificates and randomized hostnames for each application sesssion? [0] They insist that this provides many desirable security features. (Note that the free HTTPS certificates provided by the Sandcats.io service are renewed every week. [1]) [0] https://docs.sandstorm.io/en/latest/administering/wildcard/#why-sandstorm-needs-wildcard-dns https://docs.sandstorm.io/en/latest/administering/wildcard/#... [1] https://docs.sandstorm.io/en/latest/administering/sandcats/#features https://docs.sandstorm.io/en/latest/administering/sandcats/#...