Is there going to be a different certbot for ecdsa or the switchover is automatic?
Certbot doesn’t currently request ECDSA certificates. That won’t change as part of this. A future version of Certbot will probably add support for ECDSA certificates, but it’s not tied to our new intermediates.
2 Likes
When can we expect certificates with ECDSA using certbot?
3 Likes
(Moved this to a separate topic)
I’m not sure when the Certbot team plans to launch support for ECDSA certificates. @bmw can you comment?
4 Likes
I propose the ECertbot name!
3 Likes
This feature is tracked in issue #2163 on certbots Github page. There’s a stale PR which is almost complete and there’s a second PR which is also close to being complete. Both need some work though.
In the mean time, I just continue to use my own modified certbot 
It was made when there was still a lot of internal discussion about how ECDSA should be implemented in certbot and I didn’t have the time nor the vigor to keep it going as a PR for certbot. In the mean time it seems the internal discussion has turned around a bit to my own implementation anyway
2 Likes
This feature isn’t something the Certbot team is able to prioritize ourselves for the next ~9 months, but we’d hopefully be able to do the work ourselves not long after that.
With that said, we came up with a simplified design for what we want Certbot’s ECDSA support to look like earlier this year at https://docs.google.com/document/d/18pr4F4SVim-bSR6izNV5ZYwolnvitTvmP6gqElDdZPU/edit?usp=sharing. While I can’t make any promises, if we received a well written PR implementing the behavior described under the “Initial support” section, we’d certainly try to prioritize a review of it.
3 Likes
No offence, but seriously? Another 9 months? With two PRs already there?
It's 2020 already, ECDSA is there like... many years? How can this not be some kind of relative high priority? Serious question.
I'm curious about the things that are a bigger priority than ECDSA subject keys.
2 Likes
As the maintainer of an open source project with limited resources, I find comments like this to be pretty frustrating. We have 450+ issues on GitHub and many of those also have users who are frustrated and act incredulous that we haven’t fixed the issue they care about yet.
The issues we’re prioritizing first are:
- Getting our users off of Python 2. It reached its end of life earlier this year and we’ve been actively working with our dependencies to have them keep support for Python 2 a little longer so we have time to transition users to Python 3.
- We did user testing with Certbot over a year ago and we have a number of usability improvements we want to make in response to that which we have not been able to do yet.
- We’ve easily had dozens of encoding/type issues be reported by Certbot users in different scenarios. We’re planning on adding static typing to Certbot to help us fix the existing issues and avoid new ones in the future.
- Redesign our approach to DNS challenges. We’ve had many dozens of issues and PRs opened trying to add support for various cases and what we currently have isn’t particularly usable or maintainable for us.
- Fix the problems where we know Certbot isn’t following RFC 8555 and audit the code the ensure there aren’t any more.
We’re expecting that to take us about 9 months. After that, we’re planning to turn our attention to other issues and I agree with you that ECDSA support is near the top of the priority list. I’m sorry if you would prioritize things differently, but this is what we’ve chosen to work on first.
If anyone reading this would like to see support for ECDSA subject keys in Certbot sooner, like I said in my previous post, we would gladly accept your help. We’ve received other ECDSA PRs in addition to the ones Osiris listed such as https://github.com/certbot/certbot/pull/7878. Since we published the design we’d accept, we have reviewed/responded to all of them and with the exception of https://github.com/certbot/certbot/pull/8254 which is pretty new and still being worked on, all PRs so far have been incomplete and abandoned. People are more than welcome to help with the existing PRs or create their own.
Believe me, as someone who has spent the last 5+ years of their life working on Certbot, I wish Certbot currently supported ECDSA subject keys as well as many, many other improvements, but we’re a small team doing the best we can with the resources we have. Contributions to the project are always welcome.
13 Likes
I can understand that very much and I'm sorry if I came across blunt. It's just that this feature request wasn't from yesterday and I was/am genuinely shocked/curious. I'm not counting "9 months", I'm counting "9 + a few years" since the original feature request was put forth.
I understand the need for prioritisation. But I'm sure you can agree with me that ECDSA is a wildely requested feature request, perhaps one of the most requested among the 450+ issues, of which probably most (I didn't do any research I must confess) only affect a few users possibly.
Thank you for sharing that insight. It helps a lot to create more understanding. Being transparant about these kind of things might help with that, as Let's Encrypt and certbot has – I think – a large Community willing to help.
Personally, my previous experience with my attempt in a PR for this issue wasn't very positive unfortunately. Truth be told, at that time there was a lot of internal discussion about which direction the feature needed to go, which wasn't helping. In the end, I was discouraged enough to pull the plug altogether and just keep my modifications for myself (although you have a copy 
). I've made a few more features to certbot, but I just have had a little bit too much negative experience with opening PRs/issues I'm just keeping it in my own repository. I'll stick to small PRs where I won't expect too much "trouble" like documentation and the sorts..
To keep things in perspective:
- My ECDSA support PR was submitted on March 13th 2016 (that's four and a half year ago);
- The same PR was a "soccer ball" (apparently a real label on the github repository) for almost two and a half years until it was retracted/closed;
- It's now two years later still..
And I don't mean this personally in any way, but if you read the above, can you understand the frustration?
Also, I didn't see this before, but I think it's illustrative that my post about my frustration/rudeness with how my PR was handled back in 2018 has gotten 14 thumbs ups..
3 Likes
Call for action?
Round the troupes?
Light the torches?
Offer an incentive to get this done? [a la bug bounty]
Create a committee?
Register to vote?
Increase donations?
Sign a petition?
Adopt a homeless animal?
Learn a new language?
Pray for world peace?
Shoe the shoeless?
Where do we go from here?
Is there a quick(er) path to nirvana?
2 Likes
Dust of your "Python 101" book and improve one of the existing PRs to perfection Although I'm not sure how non-collaborators could do that on Github. It's not very nice to "steal" someones PR into your own fork I think, if someones still working on it, and go behind their backs.
2 Likes
You can always copy their branch, add a few commits, and then create a PR in their repo for their branch. When they merge it, your comments will show up in their branch and thus in the original PR. Obviously that only works if you don’t need to do a rebase, and if they are still active…
3 Likes
Ah, sort of stacked PR. That’s above my git/Github paygrade 
But good to know!
2 Likes
Thanks, Osiris. I can certainly understand your frustration with that experience, and I'm grateful for your thoughtfulness about the Certbot team's limited resources. ECDSA support is our highest priority feature, and I think you've made an compelling argument that it should supersede some of the priorities currently ahead of it on the roadmap.
Thank you again for the feedback. We'll keep everyone updated about our progress towards implementation.
5 Likes
Well, I was just genuinly curious and I didn't really understand. Personally, I don't really have anything to be frustrated about (as I have a perfectly working ECDSA branch on my certbot fork.. Just not up to par for certbot 
). I guess I'm just "frustrated" because I think certbot deserves such a feature, being a wonderful client! In some way, you might see it as a compliment, although I'm pretty sure I already have a name for myself of coming across rude/blunt. I don't mean any disrespect, especially not towards @bmw.
Also, I guess there's no immediate hurry as there are still some things to be done before Let's Encrypt will be able to use the new ECDSA root and intermediates. Would be nice though to sign ECDSA end leaf certs with the Let's Encrypt ECDSA intermediate 
5 Likes
Thanks Osiris. There are no hard feelings here.
4 Likes
If you have a perfectly working implementation in your fork, and considering 4+ years later there is now a large enough uptake of ECDSA that it has become a top priority, why not re-submit your PR and let people help you flesh out the boring bits, like Documentation?
@bmw @maximillianh
If we can't get ECDSA into certbot before 9 months, any chance of getting certbot to auto-renew certs generated with a CSR as a quick workaround? I have been working on an integration that requires both RSA and ECDSA certs on the same server, and my only way of doing it with certbot to date has been generating a CSR for each, with the RSA/ECDSA keys generated on the local server. The issue is certbot does not currently re-use the CSR for renewals.
1 Like
@Ruaphoc There's already a very large and improved PR: https://github.com/certbot/certbot/pull/8254 So there's no need for my n00bishly hacked together feature 
Also, my PR was stored as a separate branch on Github 
But I recon it can be removed permanently after #8254 has been merged.
1 Like
[not to start a debate on this]
I think that logic won't change anytime soon, because there is good-enough reason to force new CSRs.
[same CSR = same private key; new CSR = new private key? (hopefully)]
Given: The user should be able to choose to keep the same key/CSR.
But how easy should it be to go against the grain?
I mean it should always be easier to just get a new one.
That is the consensus on achieving safer long-term encryption.
2 Likes