Let's make Let's Encrypt easy and simple


#58

You claim that there are “few (if any) success stories” and that Let’s Encrypt is only approachable for those who are already quite familiar with SSL and already have certificates. I have pointed out that more than 90% of certificates are for domains that never had a certificate from any CA before. I have not seen you respond to that.

Again, that’s comparing apples to oranges. Yes, CAs accept CSRs. Yes, Let’s Encrypt is a CA. Yes, Let’s Encrypt accepts CSRs. The CSR is part of the ACME protocol - the means through which Let’s Encrypt accepts CSRs is ACME. ACME solves this problem, as well as account management, domain validation, revocation, etc. There is no other way to get a certificate from Let’s Encrypt. I’d recommend taking a look at the acme draft to get a clearer picture on this.

That’s a very unfair assessment, in my opinion. What is needed is actionable feedback. Both the Let’s Encrypt and the certbot team are more than happy to make changes based on feedback (as they have demonstrated based on denaje’s post). Pointing out specific things that are missing, unclear, just plain wrong or that need to be structured differently would be a great start. With the understanding that Let’s Encrypt is, more or less, “just” a CA that happens to implement ACME, and that there are a number of separate client implementations (one of which happens to be the recommended client with automatic configuration on some, but not all platforms), what do you want to see on a “Getting started” page?


#59

rugk, That is what I thought. So it is possible for anyone who simply wants to save money to obtain a certificate from LE manually, bypassing the automatic installation and renewal. There are many spammers, distributors of viruses, curious people, and legitimate webserver maintainers who might have obtained certificates without really using the full automatic service that LE offers. Yes? No?


#60

You’re mixing up ACME with the automatic configuration provided by some clients like certbot. That part has nothing to do with ACME - it’s a feature the clients provide. All those clients use ACME. ACME doesn’t force you to automatically configure your server - it just allows you to automate the process of acquiring a certificate.

To put it another way, every single certificate issued by Let’s Encrypt was issued through ACME.

(I’m not sure how spammers and malware distributors got into this topic?)


#61

I’m also not sure. For further discussion about this see:


And as you correctly said all users who have a certificate issued by Let’s Encrypt have used the Let’s Encrypt servers (through ACME as a protocol). Of course they did not have to use set up automatic renewal or configuration.
You can also use one of the third-party clients.


#62

pfg,

“I have pointed out that more than 90% of certificates are for domains that never had a certificate from any CA before. I have not seen you respond to that.”

I haven’t responded because I am not sure what we can deduce from this. Could these be websites used to distribute malware, perhaps even secured by shared sets of private and public keys, where the users are highly motivated to overcome problems, or to use more manual methods than our promised simple solution? My point is that we have apparently only assumed, based on numbers. We have never investigated.

“Yes, Let’s Encrypt accepts CSRs. The CSR is part of the ACME protocol - the means through which Let’s Encrypt accepts CSRs is ACME. ACME solves this problem, as well as account management, domain validation, revocation, etc. There is no other way to get a certificate from Let’s Encrypt. I’d recommend taking a look at the acme draft to get a clearer picture on this.”

So my objection has not been disproven. Motivated people can obtain any number of certificates from LE, possibly working around installation problems with LE or CertBot. My other points still apply, and you haven’t answered them, just stuck to your own points, where you feel that I am wrong.

" ‘My warnings about LE’s problems remain, apparently ignored.’ That’s a very unfair assessment, in my opinion. What is needed is actionable feedback. Both the Let’s Encrypt and the certbot team are more than happy to make changes based on feedback (as they have demonstrated based on denaje’s post). Pointing out specific things that are missing, unclear, just plain wrong or that need to be structured differently would be a great start. With the understanding that Let’s Encrypt is, more or less, ‘just’ a CA that happens to implement ACME, and that there are a number of separate client implementations (one of which happens to be the recommended client with automatic configuration on some, but not all platforms), what do you want to see on a ‘Getting started’ page?"

I have already said what I wish to see, just not written it up myself, because I am not an expert at writing documentation and not an expert on LE internals. The LE home page says, in a big box, “Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Get Started”. No limitations, no restrictions, just a big, implied promise of solving the problems one finds with other CAs.

Then the Get Started page says, “Certbot, the recommended Let’s Encrypt client, automates away the pain and lets site operators turn on and manage HTTPS with simple commands.” This is followed by three lines that claims to install the client software. But “git clone” will not work if the user does not have a Github account. It will not be understood unless the user spends time understanding Github, which is not trivial. I just know you are going to reply that any webserver administrator uses Github and other respository/revision control services. But I would dispute that: webservers and open software are separate concepts. I operate real and development webservers (Linux/Apache) supporting several websites, yet I have only one Github project myself; it has nothing to do with webserver management (it is an open implementation of the Diffie-Hellman secret-sharing protocol).

I haven’t tried the clone and installation commands, so I don’t know whether problems might or might not occur, things to figure out and get right on the user’s webserver. Nothing is said about needing to add Apache directives to config files; what if ACME’s editing of the files interferes with other Apache directives already there? All these questions and more are not answered at https://letsencrypt.org/getting-started/. The only limitation mentioned is the limit on the number of new certificates issued per week. Will the instructions on this page work if I am using shared hosting, so I don’t have direct root access? (Hint: people posting here have always said ‘no’.) Will the instructions on this page work on Windows? (Hint: probably not.) But https://letsencrypt.org/getting-started/ says nothing about shared hosting or Windows, or any knowledge or experience needed by the user.

The next section gives two commands for using LE. Do they actually work this easily? The many difficulties reported on the community forum would seem to argue ‘no’ and no one has conducted useability studies, surveys of users, or any other due diligence. We have no real evidence, only your claims and assumptions.

Does the “webroot plugin” have to obtained in some way not documented here? If not, why is it mentioned? Surely obtaining this plugin will take more than a few seconds all by itself. What if there is more than one version?

I assume in the general command that example.com should be replaced with the desired domain name, but what about “/var/www/example”, “/var/www/thing”, and “m.thing.is”. Are they literals (I doubt it)? Why are we given a single cert for four domain names, when the user probably wants just two? How much time will they require to figure this out? On my Linux computer, there is NO www directory in /var . That problem alone is going to give someone some pain.

All these are not new issues; I have already discussed most above; we are going around in a circle. I’ve got to stop replying to you. It is not my responsibility to give you a detailed report that takes hours of my time to create. I see my responsibility as pointing out what the LE project needs to do now to avoid serious problems, and I have done so quite fully.


#63

I think the point he wanted to say is: 90% of the webadmins had no experience with SSL/TLS/PKI before and they successfully managed to get LE certificates, so it can’t be that hard. :wink:

That’s off-topic.

No there are rate limits. See:

(As already said:) Yes, of course. And this is good - why should not it be good?

And please use the quote feature of Discourse when quoting previous replies. (Or at least use markdon, so use > when quoting a user)


#64

I feel like we’re getting into FUD territory here. Extraordinary claims require extraordinary evidence. You cannot simply ignore any number of indicators because of your personal experience with this service.

I’m unable to follow your thought process - how did we get from “does Let’s Encrypt accept CSRs” to this statement?

First of all, before this is mentioned, there’s a link to the certbot site, which includes additional documentation.

Second, git does not require a GitHub account. I’m not sure what makes you think that is the case. Git is a program you can install on your system, usually through your package manager. git clone https://github.com/certbot/certbot will run without a GitHub account, it won’t ask for a login or anything similar.

We can argue about whether using git without any introduction is appropriate nowadays (I’d lean towards “yes”, but reasonable people can disagree). The certbot documentation works around this particular problem by using wget instead of doing a full git clone of the repository, and I imagine the “Getting started” page will reflect this (recent) change soon.

What we have is community feedback, through this forum, and documentation that is often updated based on that feedback. In a perfect world with unlimited funds, I’m sure ISRG would be happy to do all the things you suggested.

It is included by default. No additional steps needed.

I believe it is quite clear that those paths are webroot directories, given that this term is mentioned in the sentence before the code, and that the sentence after says “[…] will place files below /var/www/example to prove control of the first two domains, and under /var/www/thing for the second pair”. If you’re running your own web server, you should know what the root directory of your web server is (I can’t think of a scenario where you wouldn’t - there’s no way to utilize a web server without knowing that).

The reason why multiple domains are used here is to demonstrate that you can pass multiple webroot paths, i.e. one per domain or one for special subdomains.

Sorry you feel that way. That’s what I was getting at with actionable feedback being preferable to “abstract” criticism - it almost never gets anywhere, because while everyone agrees that “things could be better”, there’s no list of items to start working on. That is especially true for Open Source projects.

Your point about git falls in the “actionable feedback” category (even if we disagree on the severity) and should probably be replaced by the wget command used on the certbot site. It might even be worth considering whether creating a simpler “Getting started” page that only gives a short description of the client ecosystem, with links to the documentation of various clients (i.e. Running Linux/BSD? --> certbot link, Windows? --> link to Windows clients, Shared hosting? --> …, etc.)


#65

The number is unknown so I’m not going to pretend it’s large. We cannot assume that everyone, or even almost everyone, having problems are going to look through the threads or even complete the registration process to start one. If the effort to request for help is too high in people’s perspective, there is a danger that they will simply give up or ask someone else.

As far as the documentation goes, it serves its purpose for the tech-savvy part of the population. The long-term goal should be to reach the audience of those who have just started learning. Last time I checked, they need HTTPS too.


#66

I’ve already said it: Those people aren’t running their own servers. In almost all cases, they are or should be customers of a provider that is handling the technical side. They should be using a LE plugin in their management interface, not an LE client directly.

If you mean people who are learning to admin a server, they should be able to read into and get running an LE client on their own. The existing documentation is perfectly sufficient for that IMHO.


#67

I don’t want to get involved in all the back and forth that has been going on in this thread, but I must say that I do disagree with this statement. I have been a Linux user for 10 years and have been admining servers for 7+. I’m certainly far from the most knowledgeable person regarding Linux admin, but I know my way around Nginx and Arch Linux quite well, and I have installed multiple EV certs manually without any trouble. Now that I know what I am doing with LE, I would say that obtaining and renewing certs is easier than the manual process, but the first few times I tried to do it, I was very confused by the documentation and did not know what parameters to use or why the cert process was failing. The docs are a little better now, but I believe they could still be improved significantly. Looking through my browser history, it seems that at one point I searched Google for “how the f*** do I use letsencrypt” because I was so aggravated by the renewal process failing with an unhelpful error message.

I should also note that I never posted on the LE forums for help. Possibly because I was stubborn and/or I figured I was doing something wrong. If a post (or series of posts more likely) would have fixed my problems, then that is 100% my fault for being too prideful. Nonetheless, I could see how a lot of people would look at the docs and think “This should be super easy, but it’s not working. That means I must be doing something wrong.”


#68

All:

I’m afraid that a Wikipedia editor has deleted the Principles section that I added to WP at https://en.wikipedia.org/wiki/Let’s_Encrypt (see my announcement above). The reason given was that this material (copied from the LE About page), cannot be copied, due to the license on page https://letsencrypt.org/trademarks/.

If anyone here at LE shares my feeling that the section should be restored, we need written permission from the holder of the ISRG trademarks to copy the About principles list to WP. Since I have no idea who that might be, and my initial enthusiasm has been used up in the attacks here, I’m giving up. If anyone can obtain written permission, post it here or email it to me and I’ll edit the section back into the article.


#69

At least in the old days (which make me misty just thinking about them), there was a manual. Now people just refer to a non-existent set of docs by saying that for any platform, googling it brings up 10 how-tos. Which is not true, but certainly takes the phenomenon to the next level. In a generation, I wonder what the excuse will be.


#70

Sorry in advance for the huge post.

Don’t apologise! It took me an embarrassing amount of reading before I felt confident I knew the difference between a protocol and a cipher, and how the key relates (or doesn’t) to both. Throw in a bunch of acronyms and it’s not surprising most people misunderstand. I still make mistakes that cause eyes to roll in the forums.

Yeah, there is a large amount of assumed knowledge on the part of most documentation. It’s not all unreasonable - if you’re capable of setting up a server and using the command line, the documentation is actually pretty good.

The problem arises when the majority of people aren’t running their own server and they’ve never used a command line. Hosting services are common, and there are plenty of people using Windows as a server and have never had to use the command line. I’m not surprised there’s currently no easy step by step guides that work for everybody since the possible combinations of situations is astronomical.

Of course, as the available clients mature they’ll be able to fill in more and more blanks for the user, give better error/feedback messages, and be generally more robust. But even then, the user will have to know what clients are available for their systems, and not be required to clone git repositories and the like (or even know what git it).

I guess I’m saying that Let’s Encrypt (the CA) is barely 6 months old. It only came out of closed beta testing at the beginning of the year, and the documentation has improved remarkably in that time. The new certbot website is excellent - you choose your OS and web server, and it provides pretty simple instructions (at least it does for FreeBSD!)

Of course, it provides very little help if something goes wrong, but as @pfg said earlier, the questions being asked in this forum are a very small percentage compared to the number of certificates successfully issued. As the clients mature, less and less will go wrong.

I also think we need to avoid the Nirvana Fallacy, and get rid of the idea we need 100% perfect guides for everybody. Cars are pretty simple to drive, but there are still people who struggle to get a driver licence!

Success will grow! The official client is still in beta, it can only get better. LE is already pretty successful and software and documentation is constantly being developed and improved upon. I haven’t seen anything that makes me think there are problems that could overwhelm us. As long as fewer and fewer users are having issues (as a proportion of the overall userbase), we’re heading in the right direction.

Probably because many of them aren’t using linux and have never seen a command line. Most of the people I see asking questions in this forum are using hosting services and don’t actually run their own servers. Those that do will often finish the thread with a “Fixed! I simply forgot to …”

Me too :innocent: Don’t let the naysayers discourage you! But at the same time, don’t think the docs or the implementation is worse than it is! Pfg is right, very few people have trouble, and of those that do (e.g. in these forums), most ultimately get the results they’re after.

Uh, I’m not why the answer is important. Pfg’s point was that the issuance numbers aren’t inflated by repeated attempts or renewals, 90% are people successfully obtaining the certs they’re after the first time (which is the goal - don’t get distracted!) Whether they use those certs for good or evil is irrelevant, just like nobody worries whether somebody is using their driver’s licence to drive the getaway car in a robbery.

I’m not sure what the issue with that is - the majority of people using LE don’t know what a CSR is, much less want to use their own. Those that what to generate their own and use it aren’t going to have issues simply using a CSR flag with the client. This is a small fringe case that doesn’t really need to be disproven. If you can generate a CSR with openssl, then you can use a CSR flag with certbot.

That’s less and less of an issue over time. I’ve never used “git clone” in my life, yet I’ve just renewed my multi-SAN cert that I obtained months ago. Git is great if you’re on an unsupported system, but LE clients are increasingly available as packaged apps. I’m on FreeBSD, and I can choose between the official client and a third party client directly from Ports/Pkg. Linux systems are the same, with multiple clients available through whatever package management systems they use.

Although you’re right, that “git clone” line probably shouldn’t be there, it’s a hangover from the early days before certbot was easily available. “Git clone” will work on just about any *nix system, so nowadays it’s basically a fallback position.

That’s a bit disingenuous. Yes, for the majority of people they do actually work that easily. The many difficulties reported in the community forums are tiny in comparison to the millions of certificates successfully issued. That’s why pfg quoted you the numbers with 90% being new domains - that’s 90% of millions of successfully issued certificates, which is the goal.

Now of course, that number may have been higher if the client and docs were better, but that’s a work in progress (on a project that’s only been publicly available for 6 months!)

No, that plugin is part of certbot, you have nothing to obtain. At this point it’s hard to tell if you’re playing Devil’s advocate or not!

You seem to have worked yourself into a mindset of this all being too hard. It’s really not. The documentation is not as unclear as you’re presenting and the clients (official and third party) work well. Much of what you’re saying is very vague and non-specific. I know you’re not a document writer but if there’s a specific issue with the docs then let us know.

Shoen and other maintainers have been very receptive to people asking for clarification or amendments to the documentation. Documentation is improved when people ask for specific omissions to be filled in or for unclear writing to be clarified. You just have to ask when you find it.

Bugger! I’m really sorry to hear that.

I’m trying to respond to your posts respectfully and considerately because I can see you’re not just complaining, you’re actively trying to contribute. I really appreciate that. I hope all the negativity in this thread doesn’t discourage you too much.


#71

DarkSteve, Thank you for your positive and supporting post. It has done much to make me feel more optimistic.

Perhaps I should clarify (again) that my main complaint is the poor quality of our Start Here page, as compared to that of many other exciting projects. I’ve given a list of these above, but please add Caddy to that list, as it uses LE as part of a webserver, and its documentation is so simple and clear that it inspires one to click “Download” and try it out. LE does not currently do so, in my opinion.

You are welcome to disagree with my opinion, and feel instead that our initial documentation is welcoming, accurate, and sets the stage for a satisfying new user experience. As I said, that opinion can be tested, using test subjects or automated surveys.

But I do want to respond (again) to your assumptions about our issuance statistics:

…the issuance numbers aren’t inflated by repeated attempts or renewals, 90% are people successfully obtaining the certs they’re after the first time (which is the goal - don’t get distracted!) Whether they use those certs for good or evil is irrelevant…

…the majority of people using LE don’t know what a CSR is, much less want to use their own. Those that what to generate their own and use it aren’t going to have issues simply using a CSR flag with the client. This is a small fringe case that doesn’t really need to be disproven.

I’m sure you know that spam and viruses are a major hazard for most users of the Internet, requiring specialized protective software that doesn’t work perfectly. But you don’t seem aware that people whose job is distributing viruses and spam use a large number of domain names. While some viruses are typically stored on an insecure WordPress page on a plumbing supply website, where they can be hidden easily from the owner of the site, others (especially when spam is involved) benefit from a dedicated website, parked under a very large number of domain names.

Spammers automatically allocate many IPs and domain names, sometimes supported by cooperative paid or bribed Registrars and other infrastructure in their countries.

If spammers were to feel that the future of the Web may involve the elimination of HTTP websites, then they may have a great interest in allocating a great number of HTTPS domain names now, in advance of the need. That would involve obtaining many certificates.

Spammers are very smart people (or their paid developers are very smart). They know that patterns of repeated attempts, renewals, etc., would reveal their presence in the LE client stream. They have long experience (in spamming) in how to avoid patterns (to foil SpamAssassin and security people alike).

This is the background information that I thought was obvious when I objected to making assumptions about hundreds of thousands of successful and apparently first-time certificate issuances. Unless a “honeypot” is set up to catch malicious users, or other very subtle security research is done, we have no idea what percentage of LE certificates are obtained by highly skilled and motivated malicious users, as compared to naive users who actually are following the Start Here page, and then getting any questions successfully answered in just minutes, as has been claimed.

It is not the fact that these people are motivated by greed that is the issue here at all. It is the simple possibility that the certificate statistics may not mean what everyone posting here thinks they mean.


#72

Back again so soon?

All Let’s Encrypt’s certificates are public documents, and they’re published automatically to the CT logs, that’s why we know independently how many there are. You’ve made some wild general assertions about these certificates but they don’t seem to be backed up by any actual facts.


#73

There is no such thing as an “HTTPS domain name”. There are domain names, for which one or more TLS certificates may or may not have been issued. In order to have LE issue a cert for a domain, the domain must exist and have authoritatively-published DNS records, and you must demonstrate control over that domain by (1) placing a cryptographically-determined piece of content at a specified URL on that domain, (2) creating a self-signed certificate for a cryptographically-determined subdomain, and serving that on your site, or (3) updating DNS records for that domain to include a cryptographically-determined token. So, if the scammers/spammers are going to try to occupy a large portion of the encrypted web, they must first own a lot of domains.

And once they own a domain, yes, they can get a cert for it. Why not? Your repeated reference to spammers and scammers is confusing, since it has no apparent connection to “mak[ing] Let’s Encrypt easy and simple”. It sounds, in fact, a lot like FUD, and if you hadn’t otherwise shown that you’re seriously interested in the project I’d just consider it such. But what are you really trying to suggest? The best I can piece together your post, it sounds like you’re saying that the issuance numbers are misleading, because some significant portion of the issued certs have been issued to spammers/scammers. Is that it? And if so, do you have any evidence to support it? And if not, please say plainly what you’re suggesting, and why.

I’m not especially interested in what spammers/scammers “may be” doing–they “may be” fornicating with dogs in rural South America, they “may be” perfecting cold fusion, or they “may be” teenagers living in their mothers’ basements and raking in their ill-gotten gains. What they “may be” doing has no bearing on this discussion. But if you have evidence of what they are doing, and it’s relevant to Let’s Encrypt, please share it.

You’ve made some good points here, some questionable ones, and some outright wrong ones (like the statement that you need a github account to use the git clone command). Mixing in borderline-FUD just weakens the rest of your points.


#74

I agree here. Although it does give some information, it lacks clarity regarding third party clients and it’s actually hard to find documentation for the official client. I know certbot is being handled by the EFF, but we could better reference it’s documentation (especially in a section called “Getting Started”).

I disagree here. Let’s Encrypt is a CA, not a downloadable program. As part of it’s beta testing and initial release, it had an (underdeveloped) client to give people a chance to use the service. Now that the client is actually developed by a third party (the EFF) I don’t think LE is in the position to have a simple “download” link.

That said, LE should really update the Getting Started page to reflect the plethora of clients available and platforms supported, as well as a clear link to certbot that indicates it’s the officially recommended client for *nix systems. It should also reference a user’s first steps if they’re using a hosting service and don’t have command line access.

I’m aware of all of that, I’m just not sure why you think it matters.

First, Let’s Encrypt’s priority is securing websites, they’ve specifically said mail servers are not part of their mission statement. Secondly, although their certificates can be used for mail servers, it’s irrelevant - mail servers don’t need a CA signed cert to use encryption. They’re happy enough using opportunistic encryption (I know, I run one).

Lastly, whether mail from domain “viagra4U” is transported from MTA to MTA via LE secured TLS or not has absolutely no bearing on whether spam filters detect it. None. In fact, by the time the spam filter sees the email, it’s well past the MTA to MTA connection.

That’s why I said “don’t get distracted! Whether they use those certs for good or evil is irrelevant!”

And Let’s Encrypt uses Google’s blacklist to ensure they don’t provide certificates for possible malware domains (such as windowsnotificationcentre.com or itunes.tk). This has previously been discussed at length.

No, their opportunistic business people like any other. Low hanging fruit pays better than jumping through hoops for that extra 10c. To get around LE’s limits requires effort and virtually no payoff. Why not send spam opportunistically encrypted rather than from some random domain secured by LE? It doesn’t make sense. This really is nothing to lose sleep over, or even be mildly concerned about.

And the background information I thought was obvious was how mail works :wink:

Well, if they’re spammers, I can guarantee you they’re not highly skilled!

Sorry to harp on this, but there is absolutely no reason to think there is any significant number of malicious sites in that 90%. I know you say we simply don’t know unless research is done, but there is simply no gain to obtaining millions of LE certificates for use in spam. None. There’s actually a loss to anybody that does it. That’s time and effort with no real-world benefit.

Now, if you’re talking about malicious websites, LE uses Google’s blacklist to ensure they’re not legitimising that kind of malware (as I linked above).

Seriously, relax. It’s not just that there is no evidence of abuse either way, it’s that there is no evidence of abuse and reason against it.

Failing that, you could do a little research yourself and go through the issued certificates. One of LE’s key principles is transparency, so you can see every single certificate they’ve issued (as stated by the LE site).

It’s all good, it really is!


#75

I haven’t read every single post here, but I do agree with the basic issues the OP brought up. when I first started to use LE, I went to another site to get let’s encrypt installed and working correctly because their guides were so much better than what LE offered at the time.

have the docs improved on LE since then? I’m not sure…I haven’t needed to look since my initial install.


#76

danb35, I know that there is no such thing as an “HTTPS domain name”. That was a fast way to say “a domain name intended for use with modern HTTPS-level security to elevate maliciousness to a new leve”. I think I will just stick with everything I said. It’s not FUD, it’s a possibility that should be considered. As to the rest, tl;dr, sorry. I have spent too much time here.


#77

andrewjs18, Please pretend you are a new visitor interested in using LE. Read the home page, click the Get Started link. You will get to the start page. Please glance over the start page and let us know if you find it simple (looks like it will work) and inspiring (makes you want to try it out).