
Let's Encrypt Stats - sinak
https://letsencrypt.org/stats/
======
kuschku
As their verification process already requires DNS to be correct, can we get a
way to verify directly via DNS?

Maybe I could put a public key in DNS, sign the CSR with the private key,
they’d poll the DNS for the key, verify, and approve it?

That would improve the ability to automate it for me a lot, without having to
use a webserver.

~~~
veeti
DNS verification is already in the ACME spec, but not yet supported by the
live servers. So the answer is "soon".

~~~
kuschku
Sad that they don’t support it yet, I’d have loved to use it. It seems so
simple and logical.

------
tenfingers
Am I the only one a bit annoyed by the 90 day expiry limit? Although the
reasoning for automation is sound, I don't see how a small expiry limit
actually improves security [as stated in one of the reasons] in any way.

Especially given the cert is basically now a requirement to get onboard with
http2 at all.

I truly appreciate the heroic efforts of let's encrypt, however that seems to
be an annoying middle step before DNSSEC.

~~~
hannob
The security argument makes sense.

The background is the following: Right now certificate revocation is
essentially broken. There are two mechanisms (CRL and OCSP), and both don't
work. CRL for obvious scalability issues and OCSP because you'd need near 100%
uptime of the OCSP responder for it to be reasonable and never have any
firewall (think of captive portals) that blocks the conncetion to OCSP.
Therefore browsers decided either to implement OCSP insecurely with a soft
fail (mostly pointless) or not at all.

So we have no working revocation. Someone hacks into your server and steals
your key and uses it to attack your users. What do you do? Of course you
revoke your cert, but it doesn't really make a difference.

People have been thinking how to fix revocation. One way would be OCSP
Stapling + must staple. But that's still a long way till this will work (the
ocsp stapling implementations of both apache and nginx would need a huge
overhaul, they are pretty bad and not up to the task). Short lived
certificates are a way to make revocation less important, because it reduces
the time a hacked key can be used.

And if this really bothers you a lot: There are two other free CAs that will
give you one year certs: StartSSL and Wosign.

------
nly
Is there a particularly large marketing presence for LE in Germany? or am I
just misinformed re: the popularity of the .de TLD?

~~~
Tomte
LE has been covered for months now in all major (online) trade magazines and
web sites, like Heise's c't and iX, Golem, Chip etc.

Additionally, .de is the most popular CCTLD, second only to .com, according to
Wikipedia (I'm not sure what that is based off, new registrations or total
registrations, though).

------
ck2
Very nice. Now do wildcards!

~~~
toyg
I know wildcards are useful and all, but they enable bad practices and
increase risk. Now that LE makes it easy to mass-request certificates, excuses
for using a wildcard are wearing thin. I'd rather LE never allowed them.

~~~
X-Istence
Wildcards allow me to serve all of my sub-domains over the same HTTP2
connection rather than causing the client to reconnect/renegotiate TLS/SSL.

This allows me to use domain sharding for those browsers still on HTTP 1.1,
yet not have a performance penalty for doing so in the case of HTTP2.

~~~
ajnin
Let's Encrypt does not support wildcard certs but they do support SAN certs,
so if your list of subdomains is fixed then you can still benefit from socket
reuse with HTTP/2.

------
samwyse
Rats! When I read the headline, I thought the article would be about a
proposal to encrypt the statistics generated by web servers.

------
stesch
I should probably switch to Apache. :-/

~~~
oliwarner
Why? The client can work pretty well with the --webroot issue method on any
webserver. Hell, if you can take your webserver offline for a short time you
can use the --standalone option's built in server.

Even where you webroot is wired into something else (a proxy, fastcgi,
uwsgi/django, etc), you can rig it to try to see if a file exists in another
directory before handing off.

    
    
        location / {
            root /web/$site/webroot;
            try_files $uri $uri/ @django;
            access_log off;
        }
    
        location @django {
            include uwsgi_params;
            uwsgi_pass unix:/web/$site/socket;
        }
    

Simple! I reuse this in many sites (hence the $site variable) but you could
decouple this and use a single directory for all sites/certificates (it
doesn't have to be in the webroot, just something nginx can read).

------
y0ghur7_xxx
Thanks to the ISRG and to all the sponsors (Except facebook. I don't like them
:)) for making Let's Encrypt.

This does not fix the CA problem, but it does a whole lot to make the internet
a safer place as it is now.

~~~
unfunco
You don't have to like Facebook to thank them, I'm not a fan of Facebook
either but appreciate their sponsorship of something so fundamental to the
web.

