Когда речь заходит о «какой ключ лучше для TLS», обсуждения часто сводятся к скорости или «крипто-моде». На практике администратору важнее другое: что реально поддерживают ваши клиенты, как выбор влияет на стоимость handshake (и CPU на пике), насколько безболезненно выпускать и ротировать сертификаты, и что умеет ваш стек (nginx/Apache + OpenSSL).
Ниже — разбор трёх вариантов, которые чаще всего всплывают в вебе: RSA, ECDSA и Ed25519. Будем смотреть именно глазами эксплуатации: публичный сайт, API за балансировщиком, внутренние сервисы, «зоопарк» клиентов, быстрые миграции и откаты.
Где в TLS вообще «живут» RSA/ECDSA/Ed25519
Упрощённо TLS состоит из двух крупных частей:
- Обмен ключами (key exchange): как стороны договариваются о секретах сессии. В современном вебе это почти всегда (EC)DHE, то есть ephemeral Diffie-Hellman.
- Аутентификация и подписи: сервер доказывает, что он «владелец домена», подписывая параметры рукопожатия приватным ключом, а клиент проверяет подпись по сертификату.
Когда вы выбираете RSA/ECDSA/Ed25519 «для сертификата», вы в первую очередь выбираете тип ключа и алгоритм подписи, которым сервер будет подписывать элементы рукопожатия. В TLS 1.3 структура проще: обмен ключами и подпись сервера разделены ещё более явно, чем в TLS 1.2.
Практический вывод: почти всегда секреты сессии получаются через ECDHE, а RSA/ECDSA/Ed25519 влияют на аутентификацию (подпись) и стоимость полного рукопожатия.
RSA: максимально совместимо и предсказуемо, но дороже на пике
RSA — исторический стандарт де-факто для TLS-сертификатов. Его главный плюс — совместимость: даже очень старые TLS-клиенты обычно переваривают RSA-сертификаты.
Плюсы RSA
- Максимальная совместимость со старыми устройствами и ПО (встроенные клиенты, старые Java-рантаймы, устаревшие прокси).
- Предсказуемость в эксплуатации: большинство CA, панелей и автоматизаций ориентированы на RSA «по умолчанию».
- Понятные параметры: обычно достаточно 2048 бит, реже используют 3072 для более консервативных политик.
Минусы RSA
- Выше нагрузка на CPU на стороне сервера именно на операциях подписи при полном рукопожатии (важно при высоком числе новых соединений).
- Больше размеры ключей и подписей, чуть больше данных в ходе рукопожатия (обычно вторично на фоне RTT, но заметно на очень «тонких» каналах и при массе новых коннектов).
Когда RSA — правильный выбор
- У вас разнородная аудитория: B2B/корп клиенты, госорганизации, старые устройства и «тяжёлый периметр».
- Нужно «включить HTTPS и не рисковать».
- Нагрузка умеренная, а вы снижаете число полных рукопожатий за счёт keep-alive, HTTP/2 и возобновления сессий.
Если вы сейчас настраиваете инфраструктуру с нуля, не забывайте, что сертификат привязан к домену: удобно заранее выстроить процесс, где домен, DNS и сертификаты управляются централизованно. Для этого может пригодиться регистрация доменов и управление DNS в одном месте с остальной инфраструктурой.
ECDSA: меньше CPU на рукопожатиях, но совместимость нужно проверить
ECDSA — подпись на эллиптических кривых (чаще P-256, реже P-384). Для веба это практичная «золотая середина»: большинство современных клиентов поддерживают ECDSA, а на сервере обычно заметно меньше CPU при большом количестве новых соединений.
Плюсы ECDSA
- Дешевле по CPU на массовых handshakes (важно, если много новых соединений и короткие сессии).
- Компактнее ключи и подписи, меньше накладные расходы в сообщениях TLS.
- Нативно ложится на современный TLS 1.3 (где шифросюиты уже не «про RSA vs ECDSA», а подпись выбирается отдельно).
Минусы ECDSA
- Хуже совместимость, чем у RSA в «экзотике»: старые стеки, часть встроенных систем, редкие комбинации старого Android/Java/прокси.
- Проблемы часто всплывают постфактум: пока не включите в проде, не увидите реальную долю клиентов, которым станет плохо (если нет хороших метрик по TLS-ошибкам).
Практическая рекомендация: dual RSA+ECDSA
Для публичного веба самый безболезненный путь часто выглядит так: вы выпускаете два сертификата на один и тот же домен — ECDSA как предпочтительный и RSA как запасной. Современные клиенты возьмут ECDSA, старые — RSA. Так вы одновременно снижаете CPU на пике и не режете совместимость.
Ed25519: отличный алгоритм, но в публичном TLS его ограничивает инфраструктура
Ed25519 — это подпись EdDSA (на Curve25519). В SSH и многих внутренних контурах Ed25519 давно воспринимается как очень удачный выбор: быстрый, компактный и с меньшим количеством «опасных настроек». Но в публичном TLS для веба упираются не в криптографию, а в поддержку по цепочке.
Плюсы Ed25519
- Быстрые операции подписи и проверки и компактные подписи.
- Хорошие свойства безопасности и меньше «пространства для ошибок» на уровне выбора кривых и параметров.
Минусы Ed25519 в контексте TLS
- Неровная поддержка в WebPKI: не все центры сертификации выпускают публичные Ed25519-сертификаты, а часть клиентов/промежуточных устройств может вести себя нестабильно.
- Зависимость от криптобиблиотеки: поддержка в nginx/Apache определяется версией и сборкой OpenSSL (или альтернатив), и иногда вы упираетесь не в конфиг, а в возможности библиотеки.
Ed25519 в TLS — это вопрос «поддерживается ли в вашей CA, клиентском парке и серверном стеке», а не «какой алгоритм красивее на бумаге».
Что реально влияет на скорость: полные handshakes, resumption и повторное использование соединений
Разница между RSA и ECDSA заметнее всего, когда у вас много новых соединений: короткие запросы, слабый keep-alive, «мобильный интернет рвётся», клиенты за NAT, балансировщики постоянно пересоздают коннекты.
Если у вас нормально настроены:
- HTTP/2 или HTTP/3 (меньше новых соединений на страницу/сессию),
- TLS session resumption (кэш/тикеты),
- адекватные keep-alive таймауты,
то доля полных рукопожатий падает, и разница по CPU может быть менее заметной. Но на пиках, а также при аномальном росте новых соединений, выигрыш ECDSA обычно снова проявляется.
Совместимость: главный критерий выбора (и почему «мониторинг важнее мнения»)
В эксплуатации «идеальный» алгоритм подписи — тот, который одновременно:
- поддерживают ваши реальные клиенты;
- поддерживает ваша CA (выпуск и перевыпуск без сюрпризов);
- поддерживает ваш серверный TLS-стек (OpenSSL и сборка nginx/Apache);
- нормально проходит через прокси/CDN/WAF/балансировщики, если они есть.
Поэтому в продакшене чаще всего получается так:
- RSA — «включили и забыли», когда совместимость важнее эффективности.
- ECDSA — «включили для эффективности», но разумно держать RSA как план Б.
- Ed25519 — чаще для внутренних контуров и контролируемых клиентов.
Если вы терминируете TLS на отдельном сервере и хотите полностью контролировать версии OpenSSL и политику шифрования, часто удобнее использовать VDS и обновлять стек по своему расписанию.
Практика для nginx: что у вас сейчас и готов ли стек к dual RSA+ECDSA
Начните с инвентаризации: версия nginx, чем он собран (OpenSSL), какие сертификаты стоят и включён ли TLS 1.3.
Проверяем версию nginx и OpenSSL
nginx -VВ выводе важна строка вида built with OpenSSL .... Именно она задаёт криптовозможности (включая поддержку алгоритмов подписи и поведение выбора сертификата).
Смотрим тип ключа и алгоритм подписи в сертификате
openssl x509 -in /etc/ssl/fullchain.pem -noout -textОбычно достаточно найти Public Key Algorithm и Signature Algorithm, чтобы понять, RSA у вас или ECDSA.
Проверяем, что сервер реально отдаёт клиентам
Полезно посмотреть, какой сертификат и какой алгоритм подписи выбирается при соединении (особенно если планируете dual). Примеры для быстрой проверки:
openssl s_client -connect example.com:443 -servername example.com -tls1_2openssl s_client -connect example.com:443 -servername example.com -tls1_3Дальше смотрите, какой сертификат пришёл, и есть ли ошибки рукопожатия в зависимости от версии протокола.
Практика для Apache: где чаще всего «ломается» ожидание при смене алгоритма
В Apache всё упирается в связку mod_ssl и OpenSSL, а проблемы при переходе на ECDSA почти всегда вызваны не самим Apache, а клиентами или промежуточными устройствами (SSL inspection, старые прокси), которые не принимают ECDSA-цепочку или не сходятся по параметрам.
Что проверить в первую очередь
- Какие протоколы реально включены (TLS 1.2/1.3), и нет ли принудительных ограничений.
- Не зажаты ли наборы шифров так, что вы случайно выбросили нужные варианты для части клиентов.
- Где терминируется TLS: Apache напрямую, перед ним балансировщик, или вы за CDN.
Если вы параллельно наводите порядок в безопасности на уровне HTTP, удобно свериться с практическими настройками заголовков: безопасные HTTP-заголовки для nginx и Apache.
Выбор алгоритма: короткая матрица решений
Если у вас массовый публичный сайт
- Самый безопасный по совместимости вариант: RSA.
- Оптимально по эффективности без потери охвата: ECDSA + RSA (dual).
Если это API для мобильного приложения
- Если вы контролируете минимальные версии ОС/SDK: обычно достаточно ECDSA.
- Если есть старые устройства и «зоопарк»: держите RSA как страховку.
Если это внутренняя инфраструктура
- Если вы контролируете клиентов и TLS-библиотеки: можно рассматривать Ed25519, но только после проверки поддержки по всей цепочке.
Типовые ошибки при переходе RSA → ECDSA/Ed25519
- Меняют сертификат и не мониторят рост TLS-ошибок (handshake failures) по логам и метрикам.
- Слишком агрессивно режут совместимость настройками протоколов и наборов шифров.
- Не учитывают промежуточные устройства: корпоративные прокси, DPI/SSL inspection, странные балансировщики.
- Путают алгоритм сертификата и обмен ключами: RSA/ECDSA/Ed25519 — про подпись и аутентификацию, а не про то, будет ли ECDHE.
Мини-чеклист перед внедрением
- Инвентаризируйте версии nginx/Apache и OpenSSL (и способ сборки).
- Определите критичные группы клиентов: браузеры, SDK, интеграции, корпоративные сети.
- Если сомневаетесь — планируйте dual RSA+ECDSA и постепенную миграцию.
- Добавьте наблюдаемость: доля TLS 1.3/1.2, ошибки рукопожатия, доля новых соединений, CPU на пике.
- Тестируйте на отдельном домене/поддомене или на canary-трафике.
Итоги: что выбрать прямо сейчас
Если нужен максимально «безопасный» выбор с точки зрения совместимости — берите RSA (обычно 2048). Если важна эффективность и вы хотите снизить CPU на пиках полных рукопожатий — выбирайте ECDSA и по возможности держите RSA как fallback. Ed25519 — отличный алгоритм, но для публичного TLS используйте его только после проверки поддержки вашей CA, клиентского парка и серверного стека.
Правильный ответ в 2026 году чаще всего звучит не как «RSA vs ECDSA», а как «какой набор алгоритмов дать клиентам, чтобы быстрые брали быстрое, а старые всё ещё работали».
Если вы выбираете площадку под веб-проект, где TLS, HTTP/2 и обновления стека должны быть максимально предсказуемыми, удобнее стартовать с тарифа под виртуальный хостинг или с отдельного VDS под свои политики и версии OpenSSL.
