Генератор CSR

Потому что закрытый ключ, попавший на чужой сервер, подпадает под собственное определение отрасли для скомпрометированного ключа — что бы этот сервер с ним ни делал потом.

Baseline Requirements CA/Browser Forum определяют это без оговорок: «Закрытый ключ считается скомпрометированным, если его значение стало известно постороннему лицу или постороннее лицо получило к нему доступ» [A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it]. Злоупотребление не требуется — достаточно того, что ключ попал к чужим.

Это не теория. В 2020 году DigiCert обнаружил 337 закрытых ключей, которые клиенты прислали вместе с запросами, отозвал все связанные сертификаты и публично об этом сообщил: «отправив закрытый ключ в DigiCert вместе с CSR, клиент скомпрометировал закрытый ключ» [by sending the private key to DigiCert along with the CSR, the customer has compromised the private key], добавив, что «из CSR мы используем только открытый ключ» [the only part of a CSR we use is the public key]. Генератор, который создаёт ключ на собственном сервере и выдаёт вам копию, по этому определению уже скомпрометировал его. Эта страница так не умеет: crypto.subtle.generateKey работает в вашем браузере, внутри изолированного фрейма, которому нельзя ни к чему подключаться, а окружающая страница видит только открытый ключ.

ECDSA P-256 — для всего нового: он так же стоек, как 3072-битный ключ RSA, гораздо меньше и допускается правилами, которым следует каждый публичный центр сертификации. RSA 2048 — когда ключ должно прочитать старое устройство.

NIST относит P-256 и RSA-3072 к одной и той же стойкости в 128 бит, а RSA-4096 вовсе не даёт собственной стойкости: следующая ступень в его таблице — 7680 бит. Так что 4096 заставляет каждого посетителя тратить лишнюю работу на рукопожатие без какого-либо описанного выигрыша. P-384 — ступень 192 бита, и Baseline Requirements допускают также P-521, но Let's Encrypt отказывается от P-521: запрос может быть вполне законным и всё же провалиться в том CA, который вы собирались использовать.

Ed25519 предлагается здесь потому, что он отлично подходит для SSH, подписи и частного CA, но ни один публичный центр сертификации не выпустит по нему TLS-сертификат. В правилах перечислены RSA и три кривые NIST, а затем сказано: «никакие другие алгоритмы или размеры ключей не допускаются» [no other algorithms or key sizes are permitted]. То же относится и к постквантовому ML-DSA: бюллетень, который разрешил бы его в публичном TLS, закрыт без принятия в октябре 2026 года. Генератор пишет об этом рядом с каждым вариантом, чтобы вы не узнавали об ограничении из письма с отказом.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr создаёт ключ и запрос за один шаг.

Генератор пишет команду для всего, что вы заполнили, включая альтернативные имена и каждое расширение, а наши тесты прогоняют её через OpenSSL, чтобы убедиться, что она создаёт тот же субъект и те же расширения, что и страница. Добавьте -subj "/CN=example.com", чтобы не отвечать на вопросы, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" для имён и -utf8, чтобы имя с диакритикой не пострадало. -nodes оставляет ключ незашифрованным: OpenSSL 3 предпочитает новое написание -noenc, но -nodes всё ещё принимает, а LibreSSL, встроенный в macOS, знает только это написание. Этот LibreSSL вообще не умеет создавать ключ Ed25519; для него нужен OpenSSL 1.1.1 или новее.

Чтобы проверить созданное: openssl req -in example.com.csr -text -verify -noout выводит каждое поле и проверяет самоподпись, а если подпись не сходится, останавливается, ничего не напечатав. Чтобы убедиться, что ключ принадлежит запросу, сравните вывод openssl req -in example.com.csr -pubkey -noout и openssl pkey -in example.com.key -pubout. Ни один стандарт не назначает CSR расширение файла, поэтому .csr, .pem, .req и .txt одинаково верны.