6 ms·
Let's Encrypt Stats
- samwyse 11y agoRats! When I read the headline, I thought the article would be about a proposal to encrypt the statistics generated by web servers.
- samwyse 11y agoRats! When I read the headline, I thought the article would be about a proposal to encrypt the statistics generated by web servers.
- ck2 11y agoVery nice. Now do wildcards!
- Sir_Substance 11y agoWant so bad, but that said, I registred 6 subdomains at once, totally painless.
- unnikked 11y agoyes, would be very useful so I can use it with a private instance of ngrok
- toyg 11y agoI 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 11y agoWildcards 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 11y agoLet'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.
- y0ghur7_xxx 11y agowhy? the signed cert is on your disk in 2 seconds. just request it on the fly. what's your use case for wildcard certs?
- nhumrich 11y agoOne usecase is a server that intercepts traffic for multiple domains. For example, a load balancer. I use AWS ELB/cloudfront for SSL termunation and they only except one cert, but they can send to multiple back ends. Then the server is routed on the host based on URL.
- nailer 11y agoYou may simply want AWS ELB to support SNI, and thus allow you to install multiple certificates.
- y0ghur7_xxx 11y agoThanks 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 11y agoYou 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.
- nly 11y agoIs there a particularly large marketing presence for LE in Germany? or am I just misinformed re: the popularity of the .de TLD?
- Tomte 11y agoLE 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).
- DasIch 11y agoNo and probably not. You're underestimating just how large the German software development/hacker community is.
- fiatjaf 11y agoIt's cheap, it's pretty, it's suitable for puns and anyone can buy .de domains, so probably it is used by many people everywhere.
- tenfingers 11y agoAm 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.
- simoncion 11y ago> however that seems to be an annoying middle step before DNSSEC. Do tell. How is LE a middle step before DNSSEC? (I would appreciate it if only tenfingers replies. I'm interested in his response, not speculation from the rest of us. :) )
- mei0Iesh 11y agoMaybe I could see annoyance about the perceived dependency on Let's Encrypt. If someone is used to setting it for multiple years, then feeling like the transaction is complete for a long while, then LE could appear too involved. It's almost like the server needs a permanent attachment to an organization, to keep pinging to ask permission to exist on the web. If everyone goes 100% HTTPS/2, with automated renewal, then one could imagine a possible scenario where Let's Encrypt going out of service would break large chunks of the web. Or gives them too much power to selectively deny renewal and break sites with unattentive admins. I'd be a little hesitant to switch commercial or critical sites to using Let's Encrypt right now. But overall, no, I like automated renewal. I think I'd choose to get a new certificate monthly, instead of 3 months. The provider I was using before with very low prices requires me to go through a manual process through their website. The main feature to me that'll cause me to switch is being able to set it and forget it. With automated monthly renewals, the 90 day expiry is extra buffer in case something goes wrong.
- tenfingers 11y agoI'm tired of downvotes without explaination. You don't see a problem with a new automation that when breaks basically brings down your website? Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else? I also really want to have the argument for improved security. Because a compromised host can now generate new certs for himself at zero cost as well, so what's the real point behind the 90 day limit? Giving NSA less time to crack your key? Thanks for clarifying.
- stesch 11y agoI should probably switch to Apache. :-/
- oliwarner 11y agoWhy? 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).
- kuschku 11y agoAs 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.
- kuschku 11y agoAs clarification: A poll for a new certificate could then be as simple as "sign the CSR with the key, do a POST to their URL with the CSR in the form data, get the results back". Not necessarily – obviously, many other approaches would work, too – but having to run a webserver to get it approved, and move files around, etc, makes the process a bit bothersome if one wants to automate it without giving the script access to the webserver, or doesn’t want to run one. EDIT: Obviously, I have to be missing something, right? What’s the error in my concept? I mean, if it was that simple, they’d have already implemented it.
- veeti 11y agoDNS verification is already in the ACME spec, but not yet supported by the live servers. So the answer is "soon".
- kuschku 11y agoSad that they don’t support it yet, I’d have loved to use it. It seems so simple and logical.