ERR_SSL_KEY_USAGE_INCOMPATIBLE: назначение ключа не подходит

ERR_SSL_KEY_USAGE_INCOMPATIBLE — ошибка Chrome и других браузеров на Chromium: сертификат сайта запрещает ключу то действие, которое нужно для выбранного способа шифрования. Сертификат может быть выдан доверенным центром, не просрочен и выписан на правильное имя — браузер всё равно оборвёт соединение.

Мы разобрали код Chromium и BoringSSL, выпустили 7 сертификатов с разным полем keyUsage и проверили их на nginx в Chrome 151, Firefox 151 и curl.

Как определить причину за минуту

Посмотрите поле keyUsage в сертификате сайта:

echo | openssl s_client -connect example.local:443 -servername example.local 2>/dev/null \
  | openssl x509 -noout -ext keyUsage

Если видите строку без Digital Signature — причина найдена: сертификат нужно перевыпустить.

Что означает ошибка

В списке ошибок Chromium (net/base/net_error_list.h) у неё код −181 и описание:

The server's certificate has a keyUsage extension incompatible with the negotiated TLS key exchange method.

То есть расширение keyUsage в сертификате сервера несовместимо с согласованным методом обмена ключами TLS. В Chromium ошибка появляется из одного места: файл net/ssl/openssl_ssl_util.cc переводит в неё ошибку библиотеки BoringSSL SSL_R_KEY_USAGE_BIT_INCORRECT.

Что такое keyUsage

Это поле сертификата X.509 (RFC 5280, раздел 4.2.1.3), которое говорит, для чего можно использовать ключ. Для сайтов важны три значения:

• Digital Signature — ключ подписывает данные. Так работают все современные шифры: ECDHE_RSA, ECDHE_ECDSA и любые шифры TLS 1.3.
• Key Encipherment — ключом шифруют секрет сессии. Так работает устаревший обмен ключами RSA (шифры вида AES128-GCM-SHA256 без ECDHE в начале).
• Key Agreement — ключ участвует в согласовании ключей. Для сертификатов сайтов почти не встречается.

Поле нужно, чтобы ключ нельзя было применить не по назначению: описание политики Chrome упоминает защиту от класса атак, использующих один протокол против другого.

Где BoringSSL проверяет поле

Проверку делает функция ssl_cert_check_key_usage в ssl/ssl_cert.cc. Если в сертификате нет расширения keyUsage, функция пропускает его. Если расширение есть, нужный бит должен стоять. Вызывают её в двух местах:

• TLS 1.2 — ssl/handshake_client.cc: для обмена ключами RSA нужен Key Encipherment, для остальных — Digital Signature. Проверка идёт после проверки цепочки сертификатов.
• TLS 1.3 — ssl/tls13_both.cc: всегда нужен Digital Signature, с комментарием «TLS 1.3 always uses certificate keys for signing». Проверка идёт сразу при разборе сертификата, до проверки цепочки, и сервер получает alert 47 (illegal parameter).

С какой версии Chrome

В описании политики Chrome RSAKeyUsageForLocalAnchorsEnabled сказано: «Starting in Google Chrome 124, this check is always enabled». В версиях 116–123 политика позволяла пропустить проверку, если соединение согласовало TLS 1.2 и сертификат RSA вёл к локальному корневому сертификату — установленному пользователем или политикой компании. Во всех остальных случаях проверка работала и тогда. Сейчас политика помечена устаревшей.

Поэтому ошибку чаще всего видят на внутренних системах: панели управления оборудованием, серверах IIS, корпоративных порталах с самоподписанными сертификатами, которые годами работали в Chrome, а после обновления перестали открываться.

Стенд: 14 сочетаний сертификата и протокола

Мы выпустили свой корневой центр и семь сертификатов для одного имени, отличающихся только полем keyUsage и типом ключа, и поставили их на nginx 1.31.6 с разными протоколами и шифрами. Chrome 151 запускали с флагом --ignore-certificate-errors, чтобы неизвестный корневой центр не мешал, curl — с нашим корневым сертификатом.

«Ошибка» в колонке Chrome — ERR_SSL_KEY_USAGE_INCOMPATIBLE. Firefox мы запускали с принятием ошибок сертификатов, поэтому его колонка показывает только то, что сам TLS проходит. Почему он принимает такие сертификаты и с доверенным центром, видно из кода — об этом ниже.

Что показал стенд:

1. Ошибка не зависит от доверия. Флаг --ignore-certificate-errors её не отключает: проверка сидит в коде рукопожатия, а не в проверке сертификата.
2. Устаревший шифр RSA меняет требование. Сертификат с одним Key Encipherment открылся, когда сервер разрешал только шифр AES128-GCM-SHA256: Chrome 151 его ещё предлагает. А сертификат с одним Digital Signature на том же шифре дал ошибку.
3. Включённый TLS 1.3 не спасает. Сервер с TLS 1.2 и 1.3 договорился с Chrome на 1.3, и там нужен Digital Signature.
4. Порядок ошибок разный. Без флага --ignore-certificate-errors Chrome на TLS 1.2 сначала сообщал ERR_CERT_AUTHORITY_INVALID — проверка цепочки идёт раньше. На TLS 1.3 сразу ERR_SSL_KEY_USAGE_INCOMPATIBLE. Если у сайта две проблемы сразу, на TLS 1.2 вы увидите сначала одну, а после её исправления — вторую.
5. ECDSA с Key Agreement на TLS 1.2 не доходит до Chrome. Сервер на OpenSSL сам отказывается: в журнале nginx «no shared cipher», в Chrome — ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Экран ошибки в Chrome 151 с английским интерфейсом — «This site can’t be reached», фраза о том, что сайт может быть временно недоступен или переехал, и код ERR_SSL_KEY_USAGE_INCOMPATIBLE внизу. Кнопки «Перейти на сайт» нет — это не ошибка сертификата, которую можно пропустить.

Почему Firefox и curl открывают сайт

Firefox. В security/certverifier/CertVerifier.cpp для сертификата сервера Firefox строит цепочку по очереди с тремя назначениями: digitalSignature (с пометкой «(EC)DHE»), keyEncipherment («RSA») и keyAgreement («(EC)DH»). Подошло любое — сертификат принят. С шифром, о котором договорились, Firefox его не сверяет. Поэтому все наши сертификаты, в которых есть хотя бы одно из трёх назначений, в Firefox работают.

curl на OpenSSL тоже не сверяет keyUsage сертификата сервера с шифром: на стенде он получил 200 от всех RSA-сертификатов, которые отверг Chrome. Если вы проверяете сайт через curl и видите успех — это не значит, что Chrome его откроет.

Что в журнале сервера

nginx пишет отказ только на уровне info — с журналом по умолчанию вы ничего не увидите. С error_log … info; на стенде было:

• TLS 1.3 — SSL_do_handshake() failed (… ssl/tls alert illegal parameter:SSL alert number 47);
• TLS 1.2 — peer closed connection in SSL handshake.

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

Почему возникает ERR_SSL_KEY_USAGE_INCOMPATIBLE

1. Самоподписанный сертификат выпущен по старому шаблону. Если RSA-сертификату указали только Key Encipherment, при обмене ключами RSA этого хватало, а Chrome до версии 124 в части случаев не проверял поле.
2. Сертификат корпоративного центра выдан по шаблону, где не указан Digital Signature.
3. Оборудование и программы со встроенным веб-интерфейсом. Статьи об этой ошибке есть, например, в базе знаний Dell (CloudLink) и на форуме Nintex (RPA Central).
4. Сервер принудительно использует устаревший шифр RSA при сертификате только с Digital Signature — обратный случай, встречается реже.

Публичные центры выдают сертификаты с Digital Signature. На 20.10.2026 сертификаты nexforce.ru (Let's Encrypt), google.com (Google Trust Services) и ya.ru (GlobalSign) содержали именно это значение. Так что у обычного сайта с сертификатом от публичного центра эта ошибка маловероятна.

Как исправить ошибку владельцу сайта

Шаг 1. Перевыпустите сертификат с правильным keyUsage

Для самоподписанного сертификата на OpenSSL 3:

openssl req -x509 -newkey rsa:2048 -nodes -keyout site.key -out site.crt -days 365 \
  -subj "/CN=example.local" \
  -addext "subjectAltName=DNS:example.local" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth"

Именно такой сертификат на стенде открылся в Chrome 151 и по TLS 1.2, и по TLS 1.3. Описание политики Chrome даёт тот же совет: если не уверены, включайте в RSA-сертификаты для HTTPS оба значения.

Для корпоративного центра сертификации поправьте шаблон сертификата веб-сервера: в нём должно быть разрешено использование ключа для цифровой подписи. После этого перевыпустите сертификаты.

Шаг 2. Установите сертификат и перезапустите сервер

Замените файлы сертификата и ключа, проверьте конфигурацию (nginx -t) и перезагрузите веб-сервер. На оборудовании — загрузите новый сертификат через его веб-интерфейс или обновите прошивку, если производитель выпустил исправление.

Шаг 3. Проверьте результат

Команда из начала статьи должна показать Digital Signature. Проверяйте именно в Chrome или другом браузере на Chromium: curl и Firefox, как показал стенд, примут и неправильный сертификат.

Что делать посетителю

Исправить ошибку на своей стороне нельзя: дело в сертификате сайта. Очистка кэша, смена сети и отключение антивируса не помогут. Если сайт нужен срочно, откройте его в Firefox — он такой сертификат примет — и сообщите владельцу или администратору, что Chrome показывает ERR_SSL_KEY_USAGE_INCOMPATIBLE.

Влияет ли ошибка на SEO

Сверяет ли keyUsage робот Google, неизвестно: страницы он загружает своим сборщиком, а не браузером Chrome, и на нашем стенде этого не проверить. На практике ошибка почти всегда касается внутренних систем, которых нет в поиске. Если её показывает публичный сайт, это срочно: страницы недоступны большинству посетителей.

Чем она отличается от похожих ошибок

Границы замера

Стенд собран 20.10.2026: nginx 1.31.6 в Docker, Chrome 151.0.7922.71 и Firefox 151.0 через Playwright, curl на OpenSSL 3.0.22. Сертификаты выпущены своим корневым центром; Chrome запускали с принятием ошибок сертификатов, Firefox — тоже, поэтому его поведение с доверенным центром мы описываем по исходному коду. Safari и Chrome на Android не проверяли. Живой сайт с этой ошибкой в публичном интернете мы не искали: ошибка возникает в основном на внутренних системах.

Источники

• Chromium: net/base/net_error_list.h, net/ssl/openssl_ssl_util.cc, описание политики RSAKeyUsageForLocalAnchorsEnabled
• BoringSSL: ssl/ssl_cert.cc, ssl/handshake_client.cc, ssl/tls13_both.cc
• Firefox: security/certverifier/CertVerifier.cpp
• RFC 5280, раздел 4.2.1.3 «Key Usage»

Похожие ошибки

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — браузер и сервер не нашли общего шифра.
• NET::ERR_CERT_AUTHORITY_INVALID — сертификат выдан центром, которому браузер не доверяет.
• ERR_BAD_SSL_CLIENT_AUTH_CERT — сайт не принял сертификат клиента.
• Ошибка 525 — Cloudflare не договорился с сервером о шифровании.

Коротко

Chrome с версии 124 сверяет поле keyUsage сертификата сервера с шифром. Для TLS 1.3 и современных шифров TLS 1.2 нужен Digital Signature; если в RSA-сертификате только Key Encipherment, будет ERR_SSL_KEY_USAGE_INCOMPATIBLE. Firefox и curl такой сертификат примут, поэтому проверять нужно в Chrome. Исправление одно — перевыпустить сертификат с keyUsage=digitalSignature,keyEncipherment.