Add support for getting RSA3072 certificates #9
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
After the migration to GreenLock v3, I can no longer get RSA3072 certificates from Let's Encrypt. It seems only two modes are supported now are ["RSA-2048", "P-256"]. Any way to add a RSA-3072 mode back? - Thanks.
Yes and no.
That it happened to work before is coincidence. RSA-2048 is recommended. RSA-3072 is NOT recommended.
Most cloud providers don't allow certificates > RSA-2048 (too much CPU spend and increase in latency on TLS handshakes).
You can provide
RSA-3072and it will create the JWKs as per spec recommendations (with the accompanying SHA-384 hash), but again, I think it was just pure accident that Let's Encrypt didn't block bad RSA-3072 configurations before, because Greenlock v2 had verifiably broken 3072 support and I don't think Let's Encrypt supports 3072 in the proper configuration.So, while this implementation is compatible with a hypothetical future version of a Let's Encrypt server that fully supports RSA-3072 and RSA-4096... I don't think such a server exists yet.
Oh, very interesting. I do understand the CPU requirements concern. Especially when dealing with a free service, one most take care not to abuse. I will close this issue, RSA2048 is plenty. Many thanks.
Keep in mind that we're still somewhere between several decades and a few hundred years away from any reasonable ability to break RSA-1024, which means that we're... several hundred millennia away from being able to break RSA-2048.
RSA-3072 is gross overtaxing of CPU cycles for a problem that will most likely never exist (especially considering that transistors only have 2-3 generations left before we're at the atom, from which we literally can't get any smaller).
And if it ever does exist, it will probably be due to a completely different computer architecture (i.e. if quantum computers are ever able to actually solve discrete math problems) which will likely require not just a "stronger" key, but an algorithm that follows entirely different principles.
👍
Understood. There are many discussions about this online, no need for this here. Again, many thanks for your support of this library.