root/greenlock.js
2
0
Fork 0
Mirror von https://github.com/therootcompany/greenlock.js.git synchronisiert 2026-01-01 07:08:39 +00:00
Code Issues 27 Releases Wiki Aktivität

Add support for getting RSA3072 certificates #9

Neues Issue
Geschlossen
2019-11-19 05:52:20 +00:00 geöffnet von Ghost · 5 Kommentare
Ghost hat 2019-11-19 05:52:20 +00:00 kommentiert
Link kopieren

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.

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.
coolaj86 hat 2019-11-19 06:03:43 +00:00 kommentiert
Besitzer
Link kopieren

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-3072 and 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.

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-3072` and 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.
Ghost hat 2019-11-19 06:08:51 +00:00 kommentiert
Autor
Link kopieren

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.

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.
Ghost hat diesen Issue 2019-11-19 06:08:51 +00:00 geschlossen
coolaj86 hat 2019-11-19 06:09:11 +00:00 kommentiert
Besitzer
Link kopieren

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.

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.
coolaj86 hat 2019-11-19 06:09:52 +00:00 kommentiert
Besitzer
Link kopieren

👍

:+1:
Ghost hat 2019-11-19 06:23:42 +00:00 kommentiert
Autor
Link kopieren

Understood. There are many discussions about this online, no need for this here. Again, many thanks for your support of this library.

Understood. There are many discussions about this online, no need for this here. Again, many thanks for your support of this library.
Anmelden, um an der Diskussion teilzunehmen.
Keine Branch/Tag angegeben
Branches Tags
Label
Keine Einträge
Kein Label
Meilenstein
Keine Einträge
Kein Meilenstein
Zuständig
Zuständige entfernen
coolaj86
Niemand zuständig
2 Beteiligte
Nachrichten
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten

Keine Abhängigkeiten gesetzt.

Referenz: root/greenlock.js#9
Keine Beschreibung angegeben.
Branch "%!s()" löschen

Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?