Вопрос или проблема
Мы пытаемся создать приложение на node.js, которое должно взаимодействовать с сервером по протоколу HTTPS (>TLS v1.2). Нам предоставили список ключей, файл сертификата для установления соединения с сервером. Node HTTPS требует файлы CA, сертификат и ключ, которые являются файлом CA, серверным сертификатом и файл(ами) ключа. При их предоставлении мы получаем следующую ошибку:
Error: unhandled critical extension.
После некоторого времени, проведенного в интернете, мы обнаружили, что в сертификате CA есть некоторые пользовательские расширения. Позже, когда мы выполнили openssl verify -CAfile ca_file.pem server_cert.pem, мы могли воспроизвести её:
error 34 at 0 depth lookup:unhandled critical extension
OK
Таким образом, это, кажется, связано с OpenSSL. Как заставить OpenSSL распознавать наши пользовательские расширения? Эти пользовательские расширения также являются критическими, поэтому мы не можем просто игнорировать ошибку, установив -ignore_critical.
У меня возникла ошибка SSL в openvpn.
VERIFY ERROR: depth=1, error=unhandled critical extension: CN=xxxx
OpenSSL: error:xxx:SSL routines:tls_process_server_certificate:certificate verify failed
Я понимаю это так, что CA настаивает на том, что некоторые значения являются критическими, и они отсутствуют или неверны в Сертификате.
Что исправило это для меня в OpenVPN, так это изменение ‘subjectKeyIdentifier’, который был установлен критически=ВЕРНО, на ЛОЖЬ в CA.
Из документации OpenSSL X509_VERIFY_PARAM_set_flags:
[Для OpenSSL] по умолчанию любые необработанные критические расширения в сертификатах […] приводят к фатальной ошибке.
В Node.js HTTPS/TLS сервере решением может быть установка опции rejectUnauthorized в false. Если клиентский сертификат отклоняется (проверяется из req.client.authorized во время запроса), мы можем вручную перепроверить (возможно, с помощью pkijs, node-forge или других пакетов, поддерживающих x509 сертификаты), игнорируя ошибочные расширения.
См. подробности в моем ответе на Stack Overflow.
Ответ или решение
Ошибка "unhandled critical extension" в OpenSSL возникает, когда сертификат содержит критические расширения, которые не могут быть обработаны или не распознаны системой верификации. Это проблема, которая часто проявляется при работе с коннекциями HTTPS или TLS, особенно когда применяются нестандартные или кастомные расширения в сертификатах.
Потенциальные решения проблемы:
-
Анализ и корректировка сертификата:
- Проверьте сертификат, который вызывает ошибку, с помощью команды
openssl x509 -text -noout -in server_cert.pem. Это поможет вам увидеть, какие критические расширения включены. - Если возможно, измените критичность расширения на non-critical, если это не нарушает требования вашего применяемого сервиса или протокола. Например, с помощью OpenSSL конфигурации можно изменить поле
subjectKeyIdentifierна non-critical.
- Проверьте сертификат, который вызывает ошибку, с помощью команды
-
Использование альтернативных библиотек:
- Если изменение сертификата не представляется возможным, рассмотрите использование альтернативных библиотек для управления сертификатами, таких как
pkijsилиnode-forge, которые могут помочь в обработке нестандартных расширений.
- Если изменение сертификата не представляется возможным, рассмотрите использование альтернативных библиотек для управления сертификатами, таких как
-
Изменение настроек OpenSSL:
- Обычно OpenSSL считает любые необработанные критические расширения за фатальную ошибку. Однако в OpenSSL можно настроить флаг
X509_V_FLAG_IGNORE_CRITICAL(если ваша задача позволяет игнорирование) для игнорирования данное условие. Это требует внимательного подхода, чтобы не снижать безопасность. - Также можно настроить проверочные флаги и параметры в OpenSSL для более точной работы с расширениями.
- Обычно OpenSSL считает любые необработанные критические расширения за фатальную ошибку. Однако в OpenSSL можно настроить флаг
-
Настройки в Node.js:
- Как временное решение, можно использовать
rejectUnauthorized: falseв настройках HTTPS сервера в Node.js. Но это может снизить уровень безопасности и открыть систему для атак типа Man-in-the-Middle (MITM). - Рекомендуется при необходимости использовать данную опцию с последующей ручной проверкой сертификата на стороне сервера.
- Как временное решение, можно использовать
-
Консультация с CA:
- Если возможно, свяжитесь с центром сертификации (CA), чтобы обсудить возможность изменения критических расширений в новом сертификате, который поддерживает ваш клиент и сервер.
Заключение
Проблема с обработкой критических расширений в OpenSSL требует комплексного подхода, включающего аутентичную проверку сертификатов и корректную настройку серверного окружения. Убедитесь, что все изменения в настройках безопасности и верификации соответствуют стандартам вашей организации и не открывают потенциальные уязвимости в системе. Правильная конфигурация и ясное понимание работы TLS и HTTPS помогут вам избежать подобных ошибок в будущем.
Если проблема остается актуальной, рекомендуется обратиться к более подробной профессиональной документации или поддержке OpenSSL/Node.js для получения расширенной информации и помощи.