Let's Encrypt is... okay.

Comments 2

i’m generally not a fan of Let’s Encrypt, especially what with their recent privacy leak. and they only support 2048-bit RSA (not 4096-bit), and SHA256 instead of SHA512. (i’m perfectly willing to spend some extra cycles.)

granted, i can only get SHA256 with Thawte but at least they let me do 4096-bit.

so while i use (and like) thawte certs (which i’ll continue to use for the landing site and for the bdisk site), i’ll probably use Let’s Encrypt for git.SQRT0, bugs.SQRT, and devblog.SQRT. (and games.SQRT too which is another project in the works.)

as usual, the Archwiki article is at least a good starting point. however, something to keep in mind if you follow their nginx instructions is you need to (as root, of course):

mkdir -p /var/lib/letsencrypt/.well-known/acme-challenge
cd /var/lib/letsencrypt/.well-known/acme-challenge

as the nginx snippet they give there isn’t entirely complete since it’s missing the dirs.

0 SQRT is shorthand for “square root”. a.k.a. square-r00t.net. a.k.a. r00t^2.

Categories Meta, InfoSec


  1. Taters

    My biggest issue out of the gate with LE was that it tore down the slight barrier that was the cost and verification done with traditional CAs. Ever since LE came about, you’re seeing a lot more scammers with valid https sites. I know a lot of us in the industry used to focus on https as a simple way for users to see that they weren’t being scammed, and whether that was a good idea or not, it still happened.

    But I suppose it had to happen eventually, we needed to get legitimate businesses to start moving to ssl by breaking down that (tiny) barrier. But, I came here to rant, not to be logical.

  2. brent

    those are some good points, taters.

    i think it’s important to note that you’ll still not very likely to see a scammer with an EV cert, but nonetheless, still valid argument.

    i’d say there’s three things we would need to have “Good ™” web security:

    * available to all free of charge/extremely accessible pricing
    * unfederated (because fuck CA’s, they’ve shown themselves to be incompetent)
    * still able to assign trust/confidence in the integrity of the authenticity

    the only method i can think of that would satisfy all three is if someone implemented some kind of web-of-trust model, like what PGP/GnuPG has, for the web realm. it’s unfederated, you would control your own PKI (and ANYONE would be able to sign you to verify your authenticity), and there’d likely be opensource implementations (it should definitely be an open standard; i can see IETF or W3C managing it).

    however, it would have to be VERY easy to use. i’m thinking integrated browser tools. and how do regular users know what signatures to trust? browsers could include signing keys by default, but at the end of the day what difference is that from including trusted root CA certs (which they already do anyways)?

    perhaps a combination of both- some sort of centralized/federated trust system like current CA PKI for TLS, and ALSO some sort of signing method available as an addon implementation.

    but AGAIN, i guess you can already do this by running your own CA and adding the CA cert to the browser’s trust store, and having that CA sign certs that other CA’s issue.

    i just really want to see some sort of widescale publicly-accessible trust system, as i think that’s the only way around it.

    anyways, thanks for the comment!


Enter your comment below. Fields marked * are required. You must preview your comment before submitting it.

← Older Newer →