Arthur T Knackerbracket has found the following story:
Let’s Encrypt said it will give users of its Transport Layer Security (TLS) certificates more time to replace 1 million certificates that are still active and potentially affected by a Certificate Authority Authorization (CAA) bug before it revokes them.
The popular free certificate authority had given users until Wednesday, March 4, 9:00 p.m. EST to replace 3 million certificates because the bug in its Boulder software—discovered and patched this past Sunday–impacted the way its software checked domain ownership before issuing certificates. However, users grumbled that this was not enough time to correct the problem.
Users and major integrators of Let’s Encrypt managed to replace more than 1.7 million of the affected certificates by the original deadline; however, more than 1 million were left that would have been revoked, causing the company to rethink its plan, a Let’s Encrypt spokeswoman told Threatpost late Wednesday.
“Rather than potentially break so many sites and cause concern for their visitors, we have determined that it is in the best interest of the health of the Internet for us to not revoke those certificates by the deadline,” Josh Aas, executive director for Let’s Encrypt said in a blog post updating users of the situation Wednesday.
The company’s plan now is to revoke 1,706,505 certificates that the company is confident were already replaced as well as “445 certificates that we treated as highest priority for revocation because, at the time we found the bug, they had CAA records that forbid issuance by Let’s Encrypt,” Aas wrote in the post.
“We plan to revoke more certificates as we become confident that doing so will not be needlessly disruptive to Web users,” he wrote.
Disclaimer: SoylentNews uses Let's Encrypt certificates.
Previously:
HTTPS for All: Let's Encrypt Reaches One Billion Certificates Issued [Updated]
Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web
Related Stories
Professor J. Alex Halderman, the noted election security researcher, along with his co-authors, have published a summary of Let's Encrypt, its components, and what it does. (Warning for PDF.) The service Let's Encrypt is a free, automated, open certificate authority (CA) to provide TLS certificates. These are usually for web sites, enabling them to provide HTTPS connections.
Since its launch in late 2015, Let's Encrypt has grown to become the world's largest HTTPS CA, accounting for more currently valid certificates than all other browser-trusted CAs combined. By January 2019, it had issued over 538 million certificates for 223 million domain names. We describe how we built Let's Encrypt, including the architecture of the CA software system (Boulder) and the structure of the organization that operates it (ISRG), and we discuss lessons learned from the experience. We also describe the design of ACME, the IETF-standard protocol we created to automate CA–server interactions and certificate issuance, and survey the diverse ecosystem of ACME clients, including Certbot, a software agent we created to automate HTTPS deployment. Finally, we measure Let's Encrypt's impact on the Web and the CA ecosystem. We hope that the success of Let's Encrypt can provide a model for further enhancements to the Web PKI and for future Internet security infrastructure.
[...] Prior to our work, a major barrier to wider HTTPS adoption was that deploying it was complicated, expensive, and error-prone for server operators. Let's Encrypt overcomes these through a strategy of automation: identity validation, certificate issuance, and server configuration are fully robotic, which also results in low marginal costs and enables the CA to provide certificates at no charge. We designed Let's Encrypt to scale to the size of the entire Web. In just over three years of operation, it is well on its way: it has issued over 538 million certificates and accounts for more valid browser-trusted certificates than all other CAs combined. We hope that in the near future, clients will start using HTTPS as the default Web transport. Eventually, we may marvel that there was ever a time when Web traffic traveled over the Internet as plaintext.
Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web, Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, Pages 2473-2487 (DOI: 10.1145/3319535.3363192
Earlier on SN:
Let's Encrypt to Transition to ISRG Root (2019)
Three Years Later, Let's Encrypt Has Issued Over 380 Million HTTPS Certificates (2018)
Let's Encrypt is Now Officially Trusted by All Major Root Programs (2018)
Let's Encrypt Takes Free "Wildcard" Certificates Live (2018)
Free Certs Come With a Cost (2017)
Let's Encrypt Issues 100 Millionth Certificate (2017)
Let's Encrypt Won its Comodo Trademark Battle - but Now Fan Tools Must Rename (2016)
Let's Encrypt Gets Automation (2015)
[Update 2020-03-02 08:34:00 UTC. Full disclosure: SoylentNews uses Let's Encrypt certificates.--martyb]
HTTPS for all: Let's Encrypt reaches one billion certificates issued:
Let's Encrypt, the Internet Security Research Group's free certificate signing authority, issued its first certificate a little over four years ago. Today, it issued its billionth.
The ISRG's goal for Let's Encrypt is to bring the Web up to a 100% encryption rate. When Let's Encrypt launched in 2015, the idea was pretty outré—at that time, a bit more than a third of all Web traffic was encrypted, with the rest being plain text HTTP. There were significant barriers to HTTPS adoption—for one thing, it cost money. But more importantly, it cost a significant amount of time and human effort, both of which are in limited supply.
Let's Encrypt solved the money barrier by offering its services free of charge. More importantly, by establishing a stable protocol to access them, it enabled the Electronic Frontier Foundation to build and provide Certbot, an open source, free-to-use tool that automates the process of obtaining certificates, installing them, configuring webservers to use them, and automatically renewing them.
When Let's Encrypt launched in 2015, domain-validated certificates could be had for as little as $9/year—but the time and effort required to maintain them was a different story. A certificate needed to be purchased, information needed to be filled out in several forms, then one might wait for hours before even cheap domain-validated certificates would be issued.
Once the certificate was issued, it (and its key, and any chain certificates necessary) needed to be downloaded, then moved to the server, then placed in the right directory, and finally the Web server could be reconfigured for SSL.
Every one to three years, you'd need to do the whole thing over again—perhaps only replacing the certificate and key, perhaps also replacing or adding new intermediate chain certificates.
Let's Encrypt, the non-profit certificate authority which provides X.509 certificates for Transport Layer Security encryption at no charge, has an update on the progress towards universal acknowledgement of its root certificate in software and firmware. The cross signature which it has purchased will expire next September, so there is a hard deadline for finalization. There are only a few barriers remaining, one of which is the old versions of Android still in use.
Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let's Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.
What can we do about this? Well, while we'd love to improve the Android update situation, there's not much we can do there. We also can't afford to buy the world a new phone. Can we get another cross-signature? We've explored this option and it seems unlikely. It's a big risk for a CA to cross-sign another CA's certificate, since they become responsible for everything that CA does. That also means the recipient of the cross-signature has to follow all the procedures laid out by the cross-signing CA. It's important for us to be able to stand on our own. Also, the Android update problem doesn't seem to be going away. If we commit ourselves to supporting old Android versions, we would commit ourselves to seeking cross-signatures from other CAs indefinitely.
It's quite a bind. We're committed to everybody on the planet having secure and privacy-respecting communications. And we know that the people most affected by the Android update problem are those we most want to help - people who may not be able to buy a new phone every four years. Unfortunately, we don't expect the Android usage numbers to change much prior to ISRG Root X1's expiration. By raising awareness of this change now, we hope to help our community to find the best path forward.
The Internet Archive has retained a copy of the original announcement for Let's Encrypt.
Previously:
(2020) Let's Encrypt Pushes Back Deadline to Revoke Some TLS Certificates
(2020) HTTPS for All: Let's Encrypt Reaches One Billion Certificates Issued [Updated]
(2019) Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web
(2019) Let's Encrypt to Transition to ISRG Root
(2018) Let's Encrypt is Now Officially Trusted by All Major Root Programs
Let's Encrypt comes up with workaround for abandonware Android devices:
Things were touch-and-go for a while, but it looks like Let's Encrypt's transition to a standalone certificate authority (CA) isn't going to break a ton of old Android phones. This was a serious concern earlier due to an expiring root certificate, but Let's Encrypt has come up with a workaround.
[...] Yesterday, Let's Encrypt announced it had found a solution that will let those old Android phones keep ticking, and the solution is to just... keep using the expired certificate from IdenTrust? Let's Encrypt says "IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. ISRG and IdenTrust reached out to our auditors and root programs to review this plan and ensure there weren't any compliance concerns."
(Score: 1) by fustakrakich on Thursday March 05 2020, @06:13PM (30 children)
The whole HTTPS thing is broken and needs to be thrown out entirely. It's only for spying anyway. Starting from scratch will be easier and more efficient.
La politica e i criminali sono la stessa cosa..
(Score: -1, Troll) by Anonymous Coward on Thursday March 05 2020, @06:24PM (2 children)
Damn! Do you study being ignorant?
Or do you just spout off with whatever blather pops into your head. It's actually kind of impressive to see someone as proud of being ignorant as you are.
Props, Fusty!
[Sung to the tune of Frosty the Snowman [youtube.com]. With apologies to Jack Rollins and Steve Nelson]
Fusty the moron is a dickless piece of shit
With an ass that talked and a mouth stuffed with Trump cock
And the political ideas of a child
Fusty the moron is a Internet shill, they say He was made of dog shit but the soylentils know
How he came to troll one day
There must have been some Trump jizz in That old cock he sucks
For when he placed it in his mouth He began to talk out of his ass
Oh, Fusty the moron
Was a dickhead through and through
And the soylentils say he could blather fact-free crap
Just the same as khallow and ari
Fusty the moron is a dickless piece of shit
With an ass that talked and a mouth stuffed with Trump cock
And the political ideas of a child
Fusty the moron is a Internet shill, they say He was made of dog shit but the soylentils know
How he came to troll one day
There must have been some Trump jizz in That old cock he sucks
For when he placed it in his mouth He began to talk out of his ass
Fusty the moron
Knew less and less each day
So he said, "let's troll
And I'll be a dickhead
Now before I'm completely ignored"
Fusty the moron
We wish he was on his way
But he shitposted more and said
"I won't go away until I prove I'm brain-damaged"
(Score: 0) by Anonymous Coward on Thursday March 05 2020, @06:28PM (1 child)
Spamming in genpop?! How uncouth!
(Score: 0) by Anonymous Coward on Friday March 06 2020, @12:09AM
'genpop'? When did you get out, friend?
(Score: 3, Interesting) by insanumingenium on Thursday March 05 2020, @06:46PM (26 children)
At best that is an argument that perfect should be the enemy of good. HTTPS isn't perfect, but it is going an awful lot of good day in and day out.
Saying it is only for spying is just plain not supportable. I assume that is meant as an argument against centralized trust, and I am not a fan of centralized trust either, but you have to at least acknowledge that distributed trust is extremely difficult to deploy properly especially at the user level.
Considering the timeline for adopting HTTPS in the first place, I am not sure where you think that starting from scratch would be either easy or efficient.
(Score: 1) by fustakrakich on Thursday March 05 2020, @06:51PM (25 children)
"Perfect" may be the enemy of the good, but "good enough" when it isn't is a much bigger problem. After a while, all the accumulating flaws begin to look suspicious.
La politica e i criminali sono la stessa cosa..
(Score: 4, Insightful) by NotSanguine on Thursday March 05 2020, @07:15PM (24 children)
Please, do explain how encrypting data across the internet is worse than *not* encrypting data across the internet. This ought to be mildly amusing.
Note that the certificates issued by Let'sEncrypt are designed to thwart in-transit eavesdropping as a *basic* level of confidentiality [wikipedia.org], with some level (given the lack of strong identity validation) of data integrity [wikipedia.org]. It is most certainly not designed for non-repudiation [wikipedia.org], nor does Let's Encrypt claim that its certificates should be used for that purpose.
The huge advantage provided by Let's Encrypt comes from helping folks without the resources or skills to implement TLS certificates.
This has had a big impact on the amount of web traffic being encrypted [duo.com]:
That's an unmitigated good and should be strongly encouraged, not "thrown out completely."
You're making an unsupportable and, frankly, inane argument, your insinuations about some sort of conspiracy included.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by FatPhil on Thursday March 05 2020, @07:32PM (16 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Redundant) by NotSanguine on Thursday March 05 2020, @07:37PM (1 child)
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by FatPhil on Friday March 06 2020, @11:44AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Insightful) by NotSanguine on Thursday March 05 2020, @07:56PM (6 children)
My apologies. I responded too quickly.
that's a completely false statement.
I have a deadbolt on my front door. It provides some level of security, but it can't stop someone from bashing the door down or taking the door off its hinges.
By your logic, my deadbolt is useless and I shouldn't bother locking my door at all.
And the same goes for passwords (they can be cracked, pulled from a hacked database, etc.). As such, passwords are useless and should never be used.
Credit/debit cards can be cloned/stolen and I can be tortured into revealing my PIN. As such, chip and pin systems are completely useless.
In fact, there is no such thing as perfect security. Which is obvious to those of us who actually *practice* infosec. Security is a continuum, and is (or should be) implemented on a scale and with the resources appropriate to whatever is being secured.
I'm really cranky if I don't have my coffee in the morning. As such, making sure my coffee, and the means to brew it, are secure is pretty important to me. So. Do I get a safety deposit box to keep my coffee and brewing rig? That would pretty much ensure the security of that stuff, right?
No. Because the *value* of such things, plus the need for access to those things, makes it impractical and a waste of resources to do so.
If, instead, I had several million dollars in bearer bonds, I'd likely expend significantly more resources in securing them. And a safety deposit box might well be a good idea, rather than keeping them next to my coffee beans in the freezer.
Even with corporate data, trade secrets, confidential documents, etc. that applies. If security that makes *required* access to such data impractical, that's too much.
Let's Encrypt isn't, and has *never* been about providing a high level of data integrity/non-repudiation for web data.
Rather, it's intended to encrypt (odd how that's in the name and everything) web data to make it *harder* to eavesdrop upon while in-transit.
Please do respond. I'd be interested to discuss this with you further -- specifically this idea that "security is binary." How did you come to that conclusion?
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0, Troll) by fustakrakich on Thursday March 05 2020, @11:57PM (1 child)
By your logic, my deadbolt is useless and I shouldn't bother locking my door at all.
Well, by my logic, if the deadbolt is made of paper mache, or if it's a black box that pops open when an airliner flies over the house [we remember our old electric garage doors] it does little more than look nice.
La politica e i criminali sono la stessa cosa..
(Score: 0) by Anonymous Coward on Friday March 06 2020, @04:16PM
Troll?
Why do people get so defensive when somebody tells them they bought snake oil?
They pushed out a system that's not ready for prime time, and it might not ever be.
(Score: 0) by Anonymous Coward on Friday March 06 2020, @05:18AM (1 child)
I am not arguing either way but your argument is not half as smart as you think and makes it stupider than it probably is. Security is not provided by the bolt on your door. Security is provided by the idea that police will consider it a grave criminal act to break that bolt and won't take you seriously if the door wasn't bolted. It is easier if you think you were living in a jungle. That bolt would show intent and intelligence of the thief if the bolts are undone and give you information whether you should spend energy in tracking it, or not.
No really! People who live in jungle bury it in the ground and guard the information about the location, not the location itself.
As I said, I am not arguing either way about the original topic but against the example you chose.
(Score: 2) by NotSanguine on Friday March 06 2020, @06:27AM
I'll ignore your obnoxious and insulting tone for the moment, as I smack your ridiculous "argument" down.
GP stated that "security is binary."
His point was that either something is secure, or it isn't and there are no gradations in security. To wit, if something isn't *completely* secure, it is completely *insecure* and therefore useless.
That, much like your "argument," is ridiculous on its face.
The example of my door is actually an *excellent* one.
The deadbolt lock certainly doesn't completely prevent someone from breaking into my apartment. But it most certainly stops someone from walking up to my door, turning the knob and walking right in or jimmying the lock.
The police have exactly *zero* to do with it. Not that I would count on them anyway. They're generally worse than useless.
One would need to bring a lock pick, a drill, a battering ram or other tools to either remove the lock or the door to gain entrance. And once they take the time to break into the lobby of my apartment building (also locked), they'd need to take the time to forcibly enter my apartment, likely making lots of noise at all points and alerting the 50+ people in the building to their presence.
That significantly raises the difficulty factor in entering my home. Is it perfectly secure? No. However, it's an *effective* mechanism for keeping unwanted folks out, and with that deadbolt, someone seeking to obtain *someone's* belongings or do harm to someone would need to expend significant effort to do so. Making that deadbolt (without any help from the po-po) quite useful.
As such, unless I am being *specifically* targeted, someone going to such lengths is extremely unlikely. And if I am being specifically targeted, there are much easier ways to gain access to my home.
As such, in the case of my door, security is most certainly *not* binary.
It's actually really amusing that you call *me* dumb, since not only didn't you understand the point of the example, but you also came up with the moronic bullshit you did. Jungle indeed. Hah!
I'm actually laughing out loud (at you) as I write this.
Since you declined to "remain silent and be thought a fool," and rather, "spoke and removed all doubt," to my mild amusement (I am pretty easily amused, so YMMV), thus making my evening more pleasant *at your expense*, I thank you AC.
Cheers!
As I proofread my post, I'm moved to laughing *at* you even more, so I decided to include this addendum. Damn you're thick!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by FatPhil on Friday March 06 2020, @11:47AM
Digital security, at least the PKI part, is supported by mathematical proofs, bits of iron aren't, in fact they come with known breaking points. Totally different realms.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by FatPhil on Friday March 06 2020, @12:03PM
Now, knowing what we now know, should those LetsEncrypt certificates be trusted?
In the past, knowing what we know now, should LetsEncrypt certificates have been trusted?
Not all 8 combinations of answers make sense, but I have a response for all of the vaguely sane ones.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Insightful) by Thexalon on Thursday March 05 2020, @08:08PM (2 children)
No, it isn't.
The number you want to measure is the amount of time and money needed to break security, and the value of the target. To use the meatspace version, no security is worse than a couple of mall cops is worse than a military base perimeter, but that doesn't mean that there aren't places where a couple of mall cops or even no security at all is appropriate, nor does it mean that a military base perimeter can't be breached by somebody willing to expend a lot of time and effort and money and lives to do so.
So, for example, I run some tiny websites on a volunteer basis for some non-profits. And there's no sense in spending a huge amount of time or money on those sites' security, because there's no sensitive data on them, and not that much of a problem if I have to shut the sites down completely for a while. By contrast, the websites for 8-figure online businesses I'm responsible for get a lot more of my monitoring and attention.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Interesting) by Anonymous Coward on Thursday March 05 2020, @09:48PM
To expand on this: the value of almost all web traffic, by itself, is approximately zero. This means for most sites, the value of any security system is approximately nothing. Thus, excepting hobbyists who like to tinker with their servers for fun, in most cases you are wasting your time if you spend more than approximately zero minutes securing your website, and you are wasting your money if you spend more than approximately zero dollars on it.
This essentially the crux of what makes Let's Encrypt so great: it brings the cost of setting up HTTPS on most sites down to somewhere between "nothing" and "bugger all": you just run certbot and you are done.
Before Let's Encrypt launched most people running webservers would have understood this cost/benefit -- even though they may not have been exactly aware of it. I attended a presentation by Seth Schoen around a year before the launch where he said something like (paraphrasing from memory) "it currently takes about an hour to setup HTTPS on a website, and from asking server administrators why they weren't using HTTPS the answer was it was too much work". Those administrators were not stupid, they were right: it was too much work. They, quite rationally, would have more rewarding things to do with that hour.
(Score: 2) by FatPhil on Friday March 06 2020, @11:55AM
All costs above more than the amount of resources available are effectively equal to infinity, as there's no test that can be performed that can distinguish them.
Of course there's the "attacks always improve" caveat, but that's more of an issue for the symmetric side, which tends to be renegotiated via the PKI side often enough that breaks would be very limited in scope, so the cost of the gains for the effort are diminished.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Insightful) by Anonymous Coward on Thursday March 05 2020, @08:20PM (2 children)
Might as well post your billing address and credit card numbers. Since security is binary and there is no 100% system connected to the internet, doing so is won't affect your security level at all. They are probably out there anyway so it isn't even new information for the internet.
(Score: 2) by FatPhil on Friday March 06 2020, @11:56AM (1 child)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by FatPhil on Friday March 06 2020, @11:58AM
Noone has my private keys.
Notice the difference?
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Friday March 06 2020, @07:28AM
The IETF would disagree [ietf.org].
(Score: 0, Offtopic) by fustakrakich on Thursday March 05 2020, @07:45PM (4 children)
You're making an unsupportable and, frankly, inane argument
Yeah, I guess you're right [informationisbeautiful.net]
La politica e i criminali sono la stessa cosa..
(Score: 0) by Anonymous Coward on Thursday March 05 2020, @08:05PM
That sites are insecure isn't a question addressed by TFS or TFA.
What's more, if you connect a device directly to the Internet, you need to assume that, as some point, it will be hacked.
However, your link and the information within it has nothing to do with the value of HTTPS or Let's Encrypt.
As such, you're talking out of your ass (again) and it smells that way too.
I guess our spammy cohort was right:
(Score: 3, Interesting) by NotSanguine on Thursday March 05 2020, @08:23PM (2 children)
Please, do explain how encrypting data across the internet is worse than *not* encrypting data across the internet. This ought to be mildly amusing.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2, Informative) by fustakrakich on Thursday March 05 2020, @08:42PM (1 child)
The real simple fatal flaw is trust...
La politica e i criminali sono la stessa cosa..
(Score: 3, Informative) by insanumingenium on Thursday March 05 2020, @09:59PM
The day you, or anyone else writes up a distributed trust model for the web that doesn't have obvious issues, and which my grandmother could realistically use, I will be on that bandwagon. Seriously, I would beat the hell out of that drum.
Until then I will use the best tools I have available, which is HTTPS/TLS. Suggesting it is useless or simply scrapping it entirely is BONKERS. I get it, centralized trust isn't a perfect model, but it isn't one chosen out of simple ignorance or malice. Yes, the implementation has room to improve, as it has been improving, and will continue to improve. Your thoughts on fixing what is broken would be appreciated, come back when you have some of those.
(Score: 0) by Anonymous Coward on Thursday March 05 2020, @11:58PM (1 child)
Encryption takes up substantially more resources than non-encryption. Beyond the raw data used for encryption itself, it also means that data can't be cached by intermediaries which increases the amount of raw traffic which needs to be sent across the network as well. Additionally, troubleshooting problems becomes much more painful. Plus it increases the operation and maintenance cost of maintaining the website, due to needing to update the certs all the time (or, if nothing else, creating and maintaining a script to do it.)
It's similar to the reason why GET requests exist in HTTP, not only POST requests.
If you say, "it's worth it due to preventing Man in the Middle attacks, injection attacks, and everything," then sure, that is a very valid position to take. However, encryption does have a cost and a negative impact as well as a positive impact.
(Score: 0) by Anonymous Coward on Friday March 06 2020, @02:32AM
That's not an argument as to how encrypting is worse than not encrypting web traffic.
In fact, on the whole, it's an argument in the other direction.
Just being contrarian or are you brain-addled?
Inquiring minds aren't interested.
(Score: 5, Informative) by NotSanguine on Thursday March 05 2020, @06:37PM (4 children)
But I renewed them early anyway.
Attempting do so (via certbot) was initially unsuccessful:
certbot renew
came back with:
Cert not yet due for renewal
Which I guess is reasonable, since the certs actually weren't up for renewal until late April.
A little research had Let's Encrypt recommending a command line of:
certbot renew --strength-renewal
Which failed, saying:
certbot: error: unrecognized arguments: --strength-renewal
However, either of the following does work:
certbot (interactive mode)
or
certbot renew --force-renewal
This:
https://checkhost.unboundtest.com/checkhost [unboundtest.com]
will let you know if your certificate is one of the affected ones.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 5, Informative) by RS3 on Thursday March 05 2020, @07:10PM (1 child)
Thank you, very helpful. Small correction: the link should omit the "checkhost" bit: https://checkhost.unboundtest.com/ [unboundtest.com]
(Score: 2) by NotSanguine on Thursday March 05 2020, @07:16PM
My bad. I copied the URL *after* doing the check and not before.
Thanks for setting us straight!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by dwilson on Thursday March 05 2020, @08:04PM (1 child)
I attempted to renew mine a bit early as well, and also got certbot: error: unrecognized arguments: --strength-renewal
I expect it's because Ubuntu 18.04.4 LTS only offers certbot v0.31.0 from the default repos, and the latest available is v1.3.0. I installed the official Certbot Ubuntu ppa, found it also offered 0.31.0, lost patience and did a manual update using certbot-auto [eff.org]. Ran it with no options, worked beautifully.
My only complaint is that they were due to expire in 2020-04, and the newly-renewed ones expire 2020-06 rather than 2021-03 or 2021-06. But I can live with that.
- D
(Score: 2) by NotSanguine on Thursday March 05 2020, @08:15PM
A good point. The issues I saw were on Fedora 31 with Certbot v.1.0.0.
Currently, like the Ubuntu repositories, the Fedora repositories don't offer the latest version.
Thankfully, an interactive run of certbot did the trick for me as well.
No, no, you're not thinking; you're just being logical. --Niels Bohr