Ошибка проверки сертификата: ключ сертификата УЦ слишком слаб во время вызова https do_handshake.

Вопрос или проблема

Наш “сервис” только что переключился на Centos 9 с Centos 8, где по умолчанию в Centos 9 используется python 3.9.21 и openssl версии 3.2.1.

Как только я запускаю сервис и пытаюсь выполнить вызов клиента, я вижу такую ошибку в файле журнала сервиса.

2025-03-03 14:26:41.666 2187 DEBUG faas.utils.wsgi [-] (2187) accepted ('10.160.41.128', 10604) server /var/lib/fas/app/lib64/python3.9/site-packages/eventlet/wsgi.py:1004
2025-03-03 14:26:41.670 2186 DEBUG faas.utils.sslutils [-] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1147) do_handshake /var/lib/fas/app/lib64/python3.9/site-packages/faas/utils/sslutils.py:169
2025-03-03 14:26:41.670 2186 DEBUG faas.utils.wsgi [-] (2186) accepted ('10.160.41.128', 10605) server /var/lib/fas/app/lib64/python3.9/site-packages/eventlet/wsgi.py:1004
2025-03-03 14:26:41.676 2187 DEBUG faas.utils.sslutils [-] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1147) do_handshake /var/lib/fas/app/lib64/python3.9/site-packages/faas/utils/sslutils.py:169

Есть идеи, как решить эту проблему?

Кстати, я уже выполнил такую настройку на Centos 9,

sudo update-crypto-policies --set LEGACY

А вот вывод команды openssl version -f:

openssl version -f 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DREDHAT_FIPS_VERSION="\"3.2.1-6034311d01fcd074\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"

А содержимое файла openssl.config:

 more /etc/crypto-policies/back-ends/openssl.config
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

Спасибо,

Джек

Ответ или решение

Уважаемый Джек,

Столкнувшись с проблемой верификации сертификата из-за слишком слабого ключа EE на вашем сервисе, после обновления с CentOS 8 до CentOS 9, вы встретили типичную проблему безопасности, связанную с изменением конфигурации и ужесточением криптографической политики в более современных системах. Проблема, с которой вы столкнулись, обусловлена применением более строгих требований к криптографическим интерфейсам и политикам в CentOS 9, которые могут быть несовместимы с используемым вами сертификатом.

Теория

Согласно современным стандартам безопасности, криптографические алгоритмы и ключи должны иметь достаточную длину и быть достаточно устойчивыми, чтобы предотвратить их взлом в разумные сроки с использованием современных вычислительных мощностей. Ваша система сообщает, что ключ, использованный в конечном сертификате (EE — End Entity), слишком слаб для установления защищённого соединения, что, скорее всего, связано с низкой длиной ключа или устаревшими алгоритмами шифрования.

CentOS 9 использует обновлённую версию OpenSSL (3.2.1), которая имеет более жесткие требования к безопасности, соответствующие текущим стандартам, что и привело к этой ошибке.

Пример

В приведённом вами случае, вы уже сделали попытку установить криптографическую политику в режим LEGACY с помощью:

sudo update-crypto-policies --set LEGACY

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

Применение

Вот несколько шагов, которые помогут вам разрешить эту проблему:

  1. Проверка и обновление сертификата:

    • Убедитесь, что длина ключа вашего конечного сертификата соответствует современным стандартам. Минимально рекомендуемая длина ключа RSA на текущий момент составляет 2048 бит. Для алгоритмов ECDSA рекомендуется использовать ключи по крайней мере с дубовинной кривой p256.
    • Если ваш сертификат не соответствует этим стандартам, обратитесь к вашему центру сертификации для обновления.
  2. Обновление конфигурации OpenSSL:

    • Убедитесь, что в файле конфигурации /etc/crypto-policies/back-ends/openssl.config установлены современные и рекомендованные параметры.
    • В вашем случае стоит попробовать уменьшить уровень безопасности до SECLEVEL=1, однако нужно помнить, что это может ослабить безопасность вашего сервиса.
  3. Просмотр журналов и обратная связь:

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

    • Убедитесь, что все применяемые библиотеки и пакеты, такие как Python и eventlet, поддерживают современные криптографические стандарты и дополнительно настроены на их использование.

Если данные действия не помогли, возможно, потребуется более детальное изучение сертификатов и среды сетевого соединения для выявления неоднозначных взаимодействий приводящих к данной проблеме. Не забудьте после внесения изменений протестировать систему в тестовой среде перед развёртыванием в производственной.

Надеюсь, эти рекомендации помогут вам устранить проблему. Если возникнут дополнительные вопросы или потребуется уточнение информации, не стесняйтесь обращаться за дополнительной помощью.

С уважением,

[Ваше имя]
[Ваша должность]
[Ваши контактные данные]

Оцените материал
Добавить комментарий

Капча загружается...