For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains - a single server you control which hosts one (or more) website(s).
All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.
And unless something really odd is happening, a small server owner will run into these problems when first setting up your LE certs for automated renewal and not any time thereafter.
Not even then. They should be using the staging servers for all testing and integration so they'll never hit the limits (a small server owner will not be needing more than 2,000 certificates per domain to be issued per week).
> How does the 3 month cert limit stem from a much more complicated problem?
Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months.
Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.
> A three months max duration limits the potential liabilities to three months.
But what attack is that blunting?
1. A bad actor with access to the system will just regenerate another LE cert and carry on.
2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base.
I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning.
90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.
If you are able to get it working once, you're generally going to be able to automate it where the 3 month limit is irrelevant. Requiring longer time horizons stem from non-standard setups.
I'll bite: sliding windows are a pain, if you hit them by accident they result in a weird self-DoS. Why not token bucket? It's a simpler algorithm to implement and less pain for the client.
If I'm unaware of these limits and use them up all at once, I'm locked out for a week instead of having to wait 1/rate to issue just one more.
Token bucket is a good idea, and I agree that it would make the user experience of hitting rate limits less onerous. We implemented sliding windows because they were straightforward to implement based on our long-term database state. I'll do some thinking about whether we can emulate a token bucket style on top of that without having to add another source of truth for rate limit information.
Letsencrypt is really a fantastic project. I can (sorta) understand why people might squeal about 90 day cert lifetimes, but just wanted to put it out there that I think that LE makes the internet a better place. @jaas adding to this thread and providing context on the decisions they made is really is just the icing on the cake :)
This thread would've made a much better example for the "users you don't want" article[1] than disabled children. It is not reasonable to expect a free service to solve all certificate related problems.
On the other hand, it shows, yet again, how dysfunctional the certificate industry is.
I really don't see what problem people are having with the 'official' certbot CLI client. It's very straightforward.
Even if you're not allowing it to directly mess with apache2 or nginx configuration files and want to run it in standalone mode. For example to get a certificate for my 'test' environment public facing smtpd:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/mail.mydomainname.us/fullchain.pem. Your cert
will expire on 2016-08-17. To obtain a new version of the
certificate in the future, simply run Certbot again.
- If you lose your account credentials, you can recover through
e-mails sent to myname@mydomainname.us.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Now we have three files, the certificate itself, the
certificate itself and the full chain, and the private key:
/etc/letsencrypt/live/mail.mydomainname.us# ls -alh
total 8.0K
drwxr-xr-x 2 root root 4.0K May 19 14:36 .
drwx------ 3 root root 4.0K May 19 14:36 ..
lrwxrwxrwx 1 root root 42 May 19 14:36 cert.pem -> ../../archive/mail.mydomainname.us/cert1.pem
lrwxrwxrwx 1 root root 43 May 19 14:36 chain.pem -> ../../archive/mail.mydomainname.us/chain1.pem
lrwxrwxrwx 1 root root 47 May 19 14:36 fullchain.pem -> ../../archive/mail.mydomainname.us/fullchain1.pem
lrwxrwxrwx 1 root root 45 May 19 14:36 privkey.pem -> ../../archive/mail.mydomainname.us/privkey1.pem
For some people, the command you gave would fail because they can't bind port 80 because apache or nginx is already listening there. And they might not be able to stop it and restart it. That's not the case if you're only running an SMTP listener, but it would be if you're already running an HTTP listener.
(I wrote the original version of standalone in certbot, but I'm just trying to stand up for the people who complain that something is complicated in their use case.)
You can use the --test-cert or --dry-run flags for this purpose. The former just makes the client use the staging server (which has higher rate limits), while the latter uses the staging server to simulate renewal, stopping short of actually storing the staging certificates (in other words: ideal for testing renewal in production).
I wish they didn't have the limit of 20 certs per registered domain.
There are a lot of use cases this blocks - Plex's use case [1] where they issued certs for all their users; large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates); and of course using ISP-assigned hostnames like host86-186-141-3.range86-186.btcentralplus.com (admittedly there are other reasons LE might not want to issue certs for that final case).
Does anyone know the reason for that limit? It seems quite low considering they allow 500 certs per IP address and 300 pending authorizations at a time :)
> large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates);
This is why we've added a form to request rate limit overrides. If mit.edu wants a higher rate limit, all they have to do is ask. We're trying to strike a balance between offering a free service that works for most people, and running the risk of abuse.
Also, even if mit.edu doesn't apply for a rate limit, people can issue certificates for 20 new sites under mit.edu per week, or 1,040 new sites per year. And in fact you can see a number of such sites in the crt.sh logs: https://crt.sh/?q=%25.mit.edu&page=1 (note: loads slowly).
Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists.
If I wanted to issue certs for a few hundred microservices running in a VPC, assuming I could get them to DNS validate, do you think I'd get approved for a rate limit exemption? Or are exemptions more of a well-you-have-to-have-a-really-good-reason thing?
Are they public microservices? You mentioned VPC, so if they're not, you may be interested in running your own CA internally. Anchor [1] was written pretty much for that purpose, but with even faster certificate cycling by default (days, not months). Of course that's for internal services only - anything internet-facing would need a trusted CA.
In your case, why not use multi-name certificates? According to the article, Let's Encrypt lets you request up to 100 names per certificate, so you could cover all your microservices with just a few certs.
For your use case, I'd recommend that you either combine them using SAN certificates, as one commenter suggested, or issue them over the span of a few weeks. Processing rate limit requests is one of the few non-automated tasks we do, and we really try to keep the volume to a minimum so we don't get overwhelmed.
The signing capacity of the HSM (or possibly HSMs, I'm not sure) holding the intermediate certificate is limited. These devices are quite expensive, so it's not that easy to scale this resource. In comparison to that, a pending authorization is just a row in some table, so that doesn't take up too many resources.
For use-cases like Plex (or generally things that require a large number of subdomains), there's now a form you can use to request rate limit adjustments[1].
HSM signing capacity is not infinite, and HSMs are expensive, but the real issue is just general DOS attacks. We aren't anywhere near our HSM capacity at the moment.
It's easy to set up tons of subdomains and request gobs of certs, which generally eats into the resources we have (database, bandwidth, HSMs). We need to limit that behavior to make sure legitimate users are getting good service.
Are you able to disclose the speed and/or cost? I know people working on cheaper HSM's. They might find the numbers useful as an assessment of how practical their own are.
Isn't that an entirely appropriate use case to say "So you'll be wanting to spend a hundred or two dollars on a wildcard cert from a vendor who sells those then"?
Just because my local pub runs a free shuttle bus to the train station, that doesn't mean they are obligated to transport my bulk freight for them.
Is it possible to request random certificates for a competing company which you know uses Letsencrypt? If yes, you could force them to not use Letsecrypt because of these limits. What count as an issued certificate?
You would not be able to increase any of the relevant rate limit counters without at least controlling a (sub)domain belonging to your competitor, or being able to send requests from the IP address your competitor is using to request certificates. There's no rate limit that would apply to your competitor short of that.
The official advice from LE about many subdomains is to combine them onto one cert with Subject Alternative Names.
This doesn't work for me - I used to do this with the Lego client using the DNS challenge for my registrar, Namecheap. Unfortunately by the second or third challenge it would hang and eventually give up. I didn't have the problem splitting the subdomains into seperate certs and running them 5 minutes apart.
The problem is likely in over restrictive rate limiting from Namecheap, but either way one of them needs to loosen up.
Does anybody else know about the Namecheap restrictions? I don't use their API for anything else but the LE DNS challenge (adding TXT records once every other month)
Or perhaps you need to revisit your decision to require "many subdomains" and consider whether it's a sensible decision if it relies on somebody else providing SSL certs for them inexpensively or for free.
You can buy a wildcard cert for under a hundred bucks these days - how much obligation do you think LetsEncrypt have to change their product to save you $100/year because of your design decisions? If LetsEncrypt (or Namecheap) don't work for you, pay someone who sells a thing that _does_ work for you (or change your requirements).
Er, hang on, I don't have a sense of entitlement about this and if it came across that way it wasn't intended.
Point is, I had only 8 domains on the cert and it didn't manage to complete most of the time. It's either an issue with the LEGO client, LE or Namecheap API.
If Namecheap sends a specific HTTP Status Code or a header like Retry-After when it performs rate limiting, this could probably be fixed in the lego DNS provider code for Namecheap. Do you happen to have any logs from when this happens? (Not sure how verbose the logging is and whether that information would be included, but it's worth a shot.)
I don't i'm afraid but I will try and pull one this weekend. Only reason I didn't do this previously is i'm pretty confident it's a Namecheap issue so i'd rather not bug the LEGO devs about it if so.
Let's Encrypt doesn't support removing subdomains from a certificate like it supports adding subdomains, so people offering per-user subdomains need to create a completely new certificate every time a user deletes their account.
All it takes is 5 (or 20?) users to delete their accounts and you've used up your Let's Encrypt quota for the entire week!
Without wildcard certificates or a method to remove subdomains from a certificate, LE is still useless for UGC sites with per-user subdomains.
1. There is no way to remove a domain from an existing certificate. Changing a certificate in any way always results in a new issuance. That's just how certificates work, nothing specific to Let's Encrypt. Certificate issuance cannot be scaled to infinity, so the same limit has to apply here (otherwise anyone could just bypass the rate limit by adding and removing subdomains and launch a DoS that way).
2. The relevant rate limit here would be 20 per week, not 5. (5 is for completely identical domain sets, i.e. duplicates)
3. Do you revoke the certificate after reissuing it without the subdomain (i.e. because it's a delegated domain and your user explicitly wants to remove trust)? If not, you might as well keep it around until your next renewal of that particular certificate and remove it at that point.
> 3. you might as well keep it around until your next renewal of that particular certificate and remove it at that point
That does seem like the best workaround for now. Idealy in the future I hope we can synchronously make a LE API call on the spot instead of having to manually manage a revocation queue.
My comment regarding revocation was to clarify that unless you're currently revoking each of these certificates after removing a subdomain, there's probably no reason why you should remove the subdomain right away (instead of with the next renewal). I'm not suggesting you should revoke the certificates if this is just an implementation detail and not about actively revoking trust.
You're right that the default tooling would not work quite the way I described, but this use-case seems to call for a more low-level ACME library anyway, and with that it should not be too complex to implement some kind of bucket system where you just split your subdomains in buckets of 100 each, and occasionally rebalance them as subdomains are removed (i.e. merge two buckets into one when they have less than 100 subdomains total, etc.)
Adding a subdomain would increase the "Certificates per Registered Domain" counter by one, just like removing a subdomain would. There's no difference.
> LE is still useless for UGC sites with per-user subdomains
Let's Encrypt is a public service, aimed at operators of individual systems who host web content or email in a casual sense, were poorly served by the complexity of getting and maintaining a TLS cert, and who empirically were basically not doing TLS.
Your posited blog host is going to be a professional or semi-professional web admin. Just call up Comodo or whoever. There's a product for that need. Let's Encrypt is not it.
I had a team member explain the project vastly differently to me. Can you provide a link that LE is only for personal/casual use?
As a webhost we have offered SSL certificates to customers for ages. Unless it's free you will see very little uptake. Which eliminates the main purpose for LE to exist, from what I was told.
I also have a rather compelling use case for far more than 20 subdomain certificates a week, but there is absolutely no "market" for that use-case - it simply increases Internet security. Which was the entire stated goal of the project, I thought.
First I've heard that LE is only for personal use :)
If you have per-user sub-domains, just get a wildcard cert, pay for it, and cover all your users all at once. Why do you need want to go through LE for that purpose?
What I personally find more inconvenient than any of those limits (as a non-power user) is the 3 month lifetime of certs. I am a windows user. Running a VM once a month just to renew my 3 certs is a huge headache. Will it really be that much of a burden to have like a year?
Not to mention the whole process is so very incredibly fugly. For something as important as it is why is there not an official online UI to manage certs? I know of atleast one online client that does exactly that but it's not official. We need the process to be as simple as making a facebook account for example. I am not very knowledgeable in certificates btw, so I may be just about to have a duh'oh moment..
Edit: Forgot to mention, I can't use auto renew scripts because my sites run on shared hosting and I don't have any kind of command line access. I have to manually upload certificates via cpanel.
I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.
I think LE's 90-day expiration reason #2 is really the key: encouraging automation. So what it really is investing effort once and working for arbitrarily period of time. If the TLS certificate renewal process cannot be automated but must be manually done for some reason, that perhaps LE certificates are really not what you are looking for.
Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.
The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix
Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.
If you're issuing lots of internal certificates, you may be interested in using Anchor [1] instead. It's designed for that use case and with own service you don't need to worry about rate limits, name limits of similar issues.
While it's designed to cycle all your certificates every day, you can still configure it for weeks/months. It's also based on credentials rather than domain verification (shameless plug, I'm Anchor developer)
You're comparing engineer time to the wildcard cert transaction price. You're neglecting to include the time for dealing with the wildcard cert (including manually remembering to renew that).
With process automation, you (or better: a collaboratively supported tool) gets progressively better at nailing renewals.
JoshTriplett's "renew every 30 days, 60 days to fix the problem" approach strikes me as inspired.
How much does it cost to manually renew your certificate every year? How much does it cost if you forget to manually renew it, or make a mistake with one of the manual steps?
This is only true if all of your engineers are operating at 100% capacity all the time. In my experience that's generally not true (and if it was they'd probably burn out pretty fast). Unless you're staffed entirely by contractors and pay by the hour?
Or just do what Let's Encrypt suggests and have a cron job that runs certbot-auto's renewal command twice a day, every day? It doesn't actually renew until nearing the end of the 3 month cycle, but by having two attempts per day it will make it far more likely to go through if the network is down or something otherwise prevents it from renewing one of the times. They, of course, also will email you repeatedly as you near the end if you haven't yet renewed.
If critical automation failure is treated as a serious bug in LE, then it should really just be a matter of time before 99.9% of them are fixed and LE can enter a state of maintenance rather than development. LE (the client) don't need to expand until it can read mail.
Yeah, I hear that frequently and I get it. The important thing, really, is that you have a cert and that you deploy HTTPS. If you can afford it and it's what you need to do to deploy HTTPS, then whether or not you get your cert from Let's Encrypt is not so important.
There are some good reasons behind the automation practices we encourage though, and if you're doing that stuff then the lifetime doesn't matter much. Worth considering regardless of who your CA is.
Same here. But you and I (or, more specifically, our firms) are not really the market for LE, at least at this point.
I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid.
Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...
I'd absolutely love to have wildcard certificates as well. I think Let's Encrypt has plans to offer them, as soon as they finish producing a new version of the ACME standard that supports authorizing them.
It looks like that should be happening soonish if I read the Github issues correctly.
https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing.
Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof.
Of course, I may be completely wrong about this, but the above is what I gather from following the issues.
> What I find more inconvenient than any of those limits (as a non-power user) is the 3 month lifetime of certs. I am a windows user. Running a VM once a month just to renew my 3 certs is a huge headache. Will it really be that much of a burden to have like a year?
You shouldn't do anything by hand to renew certificates. The short certificate lifetime encourages you to automate the process.
Clients exist for Windows, and web servers exist for Windows that include native support for ACME and Let's Encrypt.
I experimented with LetsEncrypt a few months ago, and found the process to be VERY manual. This was on a bog-standard Debian install running common web software (lighttpd) with a few vhosts. Certbot does not seem to support lighttpd, so it's: download this third party script, run this, copy that, run this, cat these files together, restart the web server process, etc. Sure, that can all be cobbled together with your own mega-script, but at that point, you start just looking for another provider (which OP did). If I were not as comfortable with the command line as I am, I'd have found the initial setup to be daunting, let alone automating it.
Even better than certbot supporting it would be if lighttpd supported ACME natively. You might file a feature request with lighttpd requesting native ACME/LE support.
Those aren't really an option for me, I use shared hosting without command line access. I realize this is an issue specific to my case but I know many other people that have their own small sites running on similar hosting as mine.
If continuing to use your current hosting provider is important to you, I suggest you ask them to integrate Let's Encrypt on their end. (That could include just letting you get Let's Encrypt certs through cPanel; it doesn't necessarily have to mean a lot of coding for them.) We've been talking to a number of providers of various shapes and sizes who are doing this or planning to do it. It's the best option for hosting environments where the customer doesn't have administrative access.
Your web hoster should integrate a way to automatically get certificates. Many already do. If they don't offer that you may want to consider using another webhoster.
What certificate issuance through a public API (ACME) allows you to do is have your server software automatically request and deploy a certificate for your hostnames (like Caddy[1]). That's probably the simplest process you can get in this space, even compared to things like certbot (which does similar things, but is not a first-party component of the web servers it supports). There's no need for any kind of UI, the best case is: give your server software the URL to an ACME server (Let's Encrypt), your hostnames and (optionally) your email address, and it'll take care of things for you. It's a bit like DHCP leases - you're probably not managing those manually either, and there's certainly no need for a fancy UI. It just works behind the scenes.
The problem is, if Let's Encrypt were to just operate like any other CA and provide certificates with lifetimes of one year (or more), there wouldn't be much of an incentive to go through any of that trouble in the first place, and users would just continue to manually renew things once every year (or not). SSL configuration would still be a PITA. With short-lived certificates, there's a big incentive for server software, control panels, shared hosting providers, etc. to provide first-party support for ACME. Clients will keep nagging them to do so or move on to competitors. This strategy seems to be working out just fine, as we're seeing many control panels (like cPanel), hosting providers (OVH) and other software (Synology DSM) add ACME support. I would not be surprised to see ACME support for all mainstream server software (think: apache, nginx, postfix, IIS, etc.) similar to Caddy within the next year or so.
What I'm getting at is that while the "forced automation" bit is currently a bit of a drag for some users, this strategy is the most likely to lead to a 100% (transport-layer) encrypted web eventually.
My point was that it incentivizes developers of server software to remove the "trouble" from your equation.
Of course (and to put it bluntly), you're free continue to put your users at risk, just like browser vendors are free to gradually break sites served via HTTP somewhere down the line.
Regarding your experience getting and managing certificates, I'm sorry to hear that you're having a difficult time.
Our goal is to encrypt the entire Web, and that means working with an almost innumerable combination of operating systems, server software, hosting providers, management interfaces, permissions, deployment strategies... Most people have a very positive experience using Let's Encrypt but it's difficult to ensure that everyone does.
It's not possible for us to build the tools necessary for every situation (financially or otherwise). Our strategy, which has been working pretty well so far, is to focus on running a secure, stable, and well-documented CA API and let our community decide what clients need to be built (and build them). This has resulted in a range of client software suitable for different situations and preferences:
This includes web-based interfaces for getting certificates from Let's Encrypt (see the "Browser" section of the client options document). Hopefully one of these will work well for you.
I was on that very page a few weeks ago. I used ZeroSSL to generate my last cert. It works great! And I understand your strategy, providing an API and letting the community work over is the absolute best you can do with the resources you have. My frustration was as a newbie fiddling with command line tools. Being completely lost. I had to read up for two straight days. Then give up for a few months. Return back, read up for two days again, discover ZeroSSL and finally have my cert. Barrier to entry was very high. Now that I'm in, it's a lot better.
>Running a VM once a month just to renew my 3 certs is a huge headache.
Not overly familiar with Windows administration (or the tools available to work with SSL/TLS stuff), but you can use Docker to automate basically all of that; IIRC it's supported on Windows now.
>Not to mention the whole process is so very incredibly fugly.
On the contrary, the process is pretty simple, even if you're going fully manual!
1. Generate a CSR for the domains you want to register
2. Place a proof of ownership somewhere on your server in a way that Let's Encrypt can verify it's there
3. Contact LE's API and tell it what domains you want to register, what you want to get signed, and where your proof is
4. Get a signed cert back. The rest is just server configuration to point to the cert.
If you use something like `certbot-auto`, it's basically a GUI step-through process.
I'm pretty sure there are letsencrypt windows clients. Which you can run every week to make sure they auto-renew. And you could do this as well by running the VM regularly, automatically.
The point of letsencrypt is to have auto-renewed certificates. It's intended to force you to automate the process.
I can't run those scripts. My site runs on shared hosting, I don't have command line access. All I have is a file manager for my 'htdocs' and standard cpanel stuff.
In fact isn't shared hosting the most common type of hosting? Any larger sites can afford paid certs anyways so letsencrypt is especially suited for smaller sites like mine, that can't afford the cert but also don't have the luxury of a dedicated machine/vps.
You're right that it's a pain for users trying to do it themselves, but some shared hosters already offer integrated LE, like DreamHost[1]; hopefully most will, if users push for it.
@Achshar: VPSes have gotten exceptionally affordable lately. DO and AWS -- some of the current market leaders for cloud instances -- both offer reasonably-performant setups with high uptime for about $5/month, and that includes command-line access.
I'd argue that among people who know about Let's Encrypt, VPS hosting is more popular than cPanel-style shared hosting.
I am a tiny single person company, VPS require a ton of setup and maintenance (for me, a noob). Believe me, I tried. I bought a vps with the intention to move over, but it was too much. I am not a unix user, I can manage xampp, but installing and making changes via command line, setting up php/mysql/apache/whatever else is more work than I get paid for. Something that just works is far more preferable to me as a college student.
Don't switch. I got a VPS for my personal site and projects a year or two ago (after 15 years of shared hosting) and if you're not comfortable on the Linux command line your server will get owned and be part of a botnet before a week is up.
Either change host or automate submission of cpanel's certificate. This could need modifying an ACME client. It might mean letsencrypt is not ready for you (yet).
I'd wait for your host to update its cPanel (unless you absolutely need https, then I'd either change hosts or buy a certificate elsewhere).
Even if you do not have command line, you probably have ftp or sftp access. If you search for filezilla in your share hosting forums, you will probably find the protocol and url.
Yeah I have FTP. But can I install certs via ftp? I mean yeah sure I guess since they are just files but won't that be like too much work? Knowing what to put where and how. cPanel is a lot simpler. Paste cert and private key, press submit.
It's not a huge time investment to learn how to do something like FTPing a cert (much less so for someone getting a Masters in Computers). Your time would be much better spent learning how to do it than spam replying "I don't have the time to learn" all over the thread. /rant
I don't know, a service like ZeroSSL (email/domains, submit, upload verification, submit, that's all) very much simpler than any command line utility, especially for simple tasks, to be done my newbies.
I think you are going to have a tough time convincing the HN crowd that a web GUI is simpler than a CLI utility; it is much more difficult to automate web GUIs than CLI utilities, and doing something like this by hand is going to seem unnecessary, given how rote this sort of task is.
Got any examples of SaaS providers who don't have low limits on their free tier offerings?
Personally I think you're badly mis-categorizing LetsEncrypt there - it's not like they're trying to bug you into signing up for a $29/month "Personal Plan" or a $199/month "Professional Plan" by keeping their limits low. They're giving their service away for free, and trying hard to only exclude the very edge cases of people who need way more resources to satisfy than the 99%.
If you've got a plan that requires hundreds of ssl certs per week to operate, and you don't have a revenue stream to pay for them, your plan needs more work. Just 'cause someone offers "free coffee", doesn't mean you can make a business out of showing up with a pickup truck full of 44gal drums and demand to have them fill you up for free so you can give it away to the customers at your restaurant...
> By SaaS I meant company offering subdomains/custom domains that needs LE - not LE itself.
Ahhh, sorry, my misunderstanding. (But an alternative comment - it's not that those SaaS companies "need LE", it's just that they want free ssl certs. I _want_ free Tesla's - my local Tesla dealership doesn't care... That doesn't make their prices "ridiculously high", it a problem with my expectations.)
> LE is not a charity. It's a business.
Not sure I (or they) agree with you there:
"Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG)."
"Consider becoming a sponsor or simply donate via PayPal."
Sure there's a wide grey line between "a business", "a 501c non-profit", and "a charity" - but if your revenue stream comes from a "please donate or sponsor us" link, not your product's pricing (whether that's a thing/service you sell, or the privacy of your free users you're selling), I think you're a lot closer to the "charity" end of that line than the "business" end.
All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.