Early Impacts of Let's Encrypt
tacticalsecret.com
tacticalsecret.com
There certainly seems to have been pent-up demand.
LE made SSL free, trusted and long-term. You could have made it twice as hard to do the initial setup and people would have jumped at the opportunity regardless.
The former doesn't allow commercial usage, while the latter operates in China. That's probably why it wasn't an option for a lot of people. (That, and the terrible UX at least in StartSSL's case.)
Incidentally, does anyone have a good way to integrate LE with EC2's load balancers?
Edit: Total brainfart, apologies; The company sending us private info as a zip was a different thing.
Sending the certificate (as opposed to the private key) via email is fine, since that only includes your public key, which is visible to every site visitor anyway.
(I agree that an automated process based on an open, standardized specification is preferable.)
You might be interested in this list of web hosts that support Let's Encrypt[1]. Generally speaking, your hoster should be able to provide a one-click interface for obtaining and installing a certificate for you, and odds are most hosts will eventually do so free of charge once HTTPS becomes mandatory.
[1]: https://github.com/letsencrypt/letsencrypt/wiki/Web-Hosting-...
- Increased resistance to surveillance. Instead of seeing the pages/information that a client downloads from your server, state actors, ISPs, local attackers, and anyone else listening only learn that the client downloaded some bytes from your server.
- Mitigation of man-in-the-middle and man-on-the-side attacks against your website. These can be as simple as someone attacking a local open Wi-Fi access point to sophisticated attacks like the Chinese DDoS against GitHub and the NSA's QUANTUM INSERT. Potential attacks range from replacing/rewriting information to attacking client machines with browser exploits.
- Better SEO rankings, Google weighs HTTPS sites higher than their equivalent insecure plaintext.
If you need a shared host that supports HTTPS, take a look at DreamHost, they have a free one-click Let's Encrypt integration.
You don't need logins/user accounts for your users to be identified. IP is sufficient in many cases, and browser fingerprint pretty much covers the other cases.
Also, if the website ever has need to become more complex, it will be easier and less error prone not to have to throw 'figure out how to implement TLS' on the pile of tasks.
Also, if permissions are the primary concern, might I recommend moving to a host that does SSL/TLS for you? Webhosts have come a long way in the last few years. Moving to a nicer one may actually save you effort in the long run.
If we are not just being hypothetical, a simple solution for you could be to register with cloudflare and run your site behind that. They will give you a free ssl certificate. This isn't as secure as running your own, since the connection between cloudflare and your server is in plain http, but it's a lot better. As an added bonus, you get a free caching layer in front of your site, which might be a good thing if you're on a small shared host.
Absolutely. The privacy of library searches has long been viewed as one of the archetypal examples of why privacy matters. A user's ISP shouldn't be able to learn what sort of books, movies, and music a library patron is interested in. And that's before we get into matters like injection of malicious content by local miscreants at your favorite cafe, or ads by mobile networks. Fundamentally, it's an issue of your users being the ones deciding what they do and do not care about being secure, and security being the default (could you imagine the emotional hurdle someone who has a real need for their privacy when using the library website would have to go through to explicitly ask for it?). The Library Freedom Project, who has been in the news a lot as of late, was in part started to push the use of SSL in all libraries, even if you "don't need it."
https://libraryfreedomproject.org/ourwork/digitalprivacypled...
https://github.com/EbookFoundation/library-privacy-pledge/wi...
It is probably more important that you do TLS/SSL than not do it because you are uncomfortable with Letsencrypt setup
here's the one I buy - https://www.ssls.com/ssl-certificates/geotrust-rapidssl
> In the first quarter of its' operation then, Let's Encrypt has far and away been used more to secure previously-unsecured (or at least untrusted) websites than simply as a cost-savings measure.
If you don't need the certs automatically installed, nginx users are generally doing well with the webroot plugin (which automatically creates files to perform the ACME challenge, regardless of what webserver is serving those files). This will also work for renewal, as long as you're able to do the initial configuration of your nginx to work with the certs you get.
We followed the instructions provided by DO[0], and aside from our mistake of leaving a previous attempt as a Virtualhost on port 443, the client just works out-of-the-box.
It automatically detects which file has the Virtualhost for port 80, asks you if you want to force redirect to https, copies your script to a new file with a Virtualhost on port 443 (adding SSL and telling Apache where to find the certs), and enables the site for you. Needless to say, my pair programmer and I were impressed thoroughly.
[0]https://www.digitalocean.com/community/tutorials/how-to-secu...
So maybe it's not wildcard vs non-wildcard, it's limit the datasets to root domain names?
It's already a requirement for anyone issuing EV certificates.
Note crt.sh is actually a Comodo website, for interrogating the CT logs.
Is the raw data available somewhere?
On a completely different and off-topic note, as someone who would normally just handle my certificate needs by piping together 10 openssl commands, your ACME client is super handy!
CT logs are populated by CAs sending their certificates to log servers. Only a few CAs (including Let's Encrypt) do this consistently at the moment, since it's only mandatory for EV certs (for now), and CAs generally move rather slowly. Certificates encountered by Googlebot during web crawling also get pushed to their log servers. Censys probably does something similar.
It's possible that there's a large number of certificates issued only for internal systems that would not end up on CT log servers and that are not accessible by public crawlers, so the numbers are probably not painting a full picture. It is, however, as close as you can get to the full picture unless every CA is willing to release their internal numbers.
I still have no idea if they are able to fix this in future.
[1] https://github.com/letsencrypt/letsencrypt/issues/1660
[2] https://community.letsencrypt.org/t/help-needed-windows-xp-s...
As an alternative you could incorporate provisioning of a Let's Encrypt certificate for the new subdomain into your deployment process since the process is designed to be automated.