Could you elaborate?
the main part of @NOYB is that the certs are valif for just 90 days
main reason is that they want to make more people use automation
-> I think first they should make the client available for more OSes (windows anyone) and the server integrations stable (apache is on alpha and only works on debian, nginx is very expermimental, according to the docs)
maybe the use of a browser interface to upload a CSR so people dont need to install a potentailly unsecure and/or unstable software just to get the cert, also a webinterface is OS-independent.
also no wildcard, I dont really know why they dont have it, it isnt as bad as the 90 day thing and maybe they might add wildcard support in the future, we never know…
/test/js/ directory. It needs someone to go build a web browser implementation. Bonus points if it utilizes WebCrypto!
Why haven’t we done it yet? It’s simple, really: there’s only a handful of us working on the project, and it’s pretty hard to build a publicly-trusted CA. It’s not like this is a well-funded startup, hiring 50 people. It’s a not-for-profit focusing on making the core, hard bit, while providing the tools needed to extend it – ACME.
I, for one, look forward to a simple browser implementation of the manual process as well.
(I, for one, also look forward to things like weekends again.)
The ACME spec doesn’t support wildcards. Let’s Encrypt, being the first CA to implement ACME, won’t support them until ACME supports them. If anyone reading this is really interested in solving the apex problem, and the other thorny bits, please join the ACME IETF mailing list and help work it out.
well seems legit for the wildcard thing but why didnt you start with the webinterface if I may ask? it seems to be the most obvious approach to upload your CSR and get the cert.
for the browser thing I think an implementation similar to startssl could be nice, login via client cert, upload CSR (or let LE make the key, for the naive users), make maybe certain settings that I dont know yet, and then get your cert.
bonus points if no js is needed (I often have issues with js failing to load and therefore buttons and stuff being unusable, especially if you just have throttled internet).
also what’s webcrypto?
but I wonder why acme doesnt do wildcards usually if I have example.com I should also be allowed to get *.example.com, at least that’s what I think.
anyway, I know that it’s not a well-funded startup, so I think you shouldfocus on making it usable until you got it working perfectly, for example by giving manual users the choice of a longer cert time.
This is only my opinion, and I don’t speak for ISRG / Let’s Encrypt - I’m just a technical advisor.
The reasons I can think of to start with the automatic client are:
- An automatic client is hard, hasn’t been done before, and demonstrates the novelty and power of ACME over traditional methods.
- Most people who configure Apache or Nginx do not know what a CSR is. Or how to protect the keys.
- Personally, I want to never have to explain to people what a CSR is again, or how to generate one.
- Also personally, but specifically about CSRs: PKCS10 is IMO an example of everything that is wrong with crypto today.
Really, I expect someone’s working on one right now, somewhere. Walk people through the OpenSSL commands to copy/paste, responses to copy/paste, toss some tasteful advertisements for Debian on there, and bam! I’ll link it from the List of Client Implementations and someone will post it on Hacker News, and people will go to down.
what’s the problem with PKCS10?
All the more reason not to complicate and convolute it with unnecessary policy politics designed to dictate personal behaviors and processes.
KISS - just provide the certs. Automated for those who can and 90 days is fine for that since it’s automatic. For the most part. But not allowing reasonably long cert lifetime for those who need to use human interactive process just removes a whole lot of interest in using LE and helping. Using the project to push unnecessary control freak policies is a real turn off too. Would probably fit right in a Microsoft.
yeah but I think it’s weird you have a client running on linux on multiple architectures (x86 for “normal PCs and servers” and ARM for Raspi proven, I dunno about others), but not on windows, which looks quite weird, wouldnt it be normal if you say that you are understaffed to focus on one architecture???
Never been done before? Doesn’t SSLMate count as an automatic client? I’ve used it for a couple of domains and it’s child’s play. I was hoping LE was going to be the free version of SSLMate but LE’s client is a bit of a PITA by comparison.
could you exaplain pita for me? this makes no sense in context:
The problem (considering Python is used) is not CPU arch, but userspace. It is different in UNIX-like and Windows. The people working on the project now are more interested in UNIX-like support (and, frankly, I can understand them). Windows s. shall land eventually, because all the specs are open. In fact, no techical reason exists for you not to organize a WG to implement a Windows ACME client / add Win support to current
I always thought that software made for one arch doesnt work at another which is one of the main reasons winRT cannot run any normal windows software…
but talking about pita, seems that multi-domain manual is a pita as well, just when I try to get a SAN let me do the same challenge for all domains, and/or leave confirmed ones intact if the same LE acc is used
If you look at the letsencrypt.org/about page its mission is pretty clear.
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.
That the goal is clearly to automate certificate provisioning. I’m afraid some of you have the wrong expectations.
just provide the certs and let users handle the security part
The problem is that there is no such thing as “optional security” (ex. see Theo de Raadt’s rants on topic). Certificates are intended to provide transport security; if they are compromised, they are effectively useless. Let’s Encrypt builds the tools which allow really easy provisioning, which helps TLS adoption in practical cases. The tools are going to be used by a lot more people than just those with infosec understanding, and I believe there should be some restrictions which make the whole ecosystem more secure.
I believe we’ll have quite a lot of guides on Let’s Encrypt for general public soon, and I would rather not see smth like
Just get a cert for two years and let it stay in there. Nah, that’s fine. Who cares about rotation anyway?
Oh, something’s not working? Did you try
It’s quite easy to draw some similarities with SELinux from this point, I think.
Something breaks? Turn SELinux off. It’s scary and it breaks stuff.
Maximum (and minimum) certificate lifetimes?
In this case, Let’s encrypt is absolutely useless for professionals that will never trust an automated utility to manage their certificates. If the aim of this project is to just accomodate the needs of a few amateur admins with no experience in editing Apache / Nginx / lighttpd config files, then I certainly don’t want to use this service…
professionals that will never trust an automated utility to manage their certificates
Sorry, do you really think that companies with a vast infrastructure like Google, Twitter or Cloudflare rotate anything by hand? For ex. Google’s certificates are valid for three months, but are exchanged once a month. So, the idea is they have a contract with some Indian outsorcing firm to go through all their SSL-termination servers every month?
You see, there are people who just want to have their own simple service set up - with no need to go through the complexities of TLS and PKI. There are amateur admins, who have a lot to learn and a lot of mistakes to make. There are enterprise admins ruling over thousands of servers, with as much as possible automated. There are also SMB-retrogrades who deem themselves “professional” while thwarting the lowly “amateurs”, lost in their ignorance (oh, dramatic!).
if you’re an experienced admin for nginx or apache, you might want to look into letsencrypt client’s webroot authentication plugin see Letsencrypt Webroot Authentication Tested on Beta invited/whitelisted domain and Using the webroot domain verification method
With webroot authentication there’s a clearer separation in that letsencrypt client doesn’t actually touch your web configuration itself - instead it just validates the domain(s) when you pass the public web root path of your domain(s) to the letsencrypt client. So you can script and do the actual web server end configuration the way you want it setup and just point to the letsencrypt client obtained ssl certificate related files.
Letsencrypt client’s webroot authentication plugin is what I am integrating into my own Centmin Mod Nginx LEMP web stack for Nginx vhost auto generation with Letsencrypt SSL certificate and auto renewal scripted support - latest progress https://community.centminmod.com/posts/20305/ (still waiting on ability to update registered LE account’s email address Clarify the --email flag requirements? though and https://github.com/letsencrypt/letsencrypt/issues/1260 for multi-domain SAN ssl).
FWIW, I’m personally also not overjoyed with the current quality of the standard ACME client, but honestly, it’s not a security issue at all. And if you don’t like it, you’re entirely free to write your own; the protocol is open, and you can build your own web interface talking to it if you’d like.
LE, as a whole, is massively useful to the Internet. The automated procedure is unusual, but I believe that’s a good thing, not a bad one.