Вопрос или проблема
Наш “сервис” только что переключился на 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 по-прежнему требует повышения уровня безопасности для конечного сертификата.
Применение
Вот несколько шагов, которые помогут вам разрешить эту проблему:
-
Проверка и обновление сертификата:
- Убедитесь, что длина ключа вашего конечного сертификата соответствует современным стандартам. Минимально рекомендуемая длина ключа RSA на текущий момент составляет 2048 бит. Для алгоритмов ECDSA рекомендуется использовать ключи по крайней мере с дубовинной кривой p256.
- Если ваш сертификат не соответствует этим стандартам, обратитесь к вашему центру сертификации для обновления.
-
Обновление конфигурации OpenSSL:
- Убедитесь, что в файле конфигурации
/etc/crypto-policies/back-ends/openssl.config
установлены современные и рекомендованные параметры. - В вашем случае стоит попробовать уменьшить уровень безопасности до SECLEVEL=1, однако нужно помнить, что это может ослабить безопасность вашего сервиса.
- Убедитесь, что в файле конфигурации
-
Просмотр журналов и обратная связь:
- Проанализируйте другие журналы и выводы системы, которые могут дать более детальную информацию о произошедшей ошибке и её причине.
-
Проверка библиотек и зависимостей:
- Убедитесь, что все применяемые библиотеки и пакеты, такие как Python и eventlet, поддерживают современные криптографические стандарты и дополнительно настроены на их использование.
Если данные действия не помогли, возможно, потребуется более детальное изучение сертификатов и среды сетевого соединения для выявления неоднозначных взаимодействий приводящих к данной проблеме. Не забудьте после внесения изменений протестировать систему в тестовой среде перед развёртыванием в производственной.
Надеюсь, эти рекомендации помогут вам устранить проблему. Если возникнут дополнительные вопросы или потребуется уточнение информации, не стесняйтесь обращаться за дополнительной помощью.
С уважением,
[Ваше имя]
[Ваша должность]
[Ваши контактные данные]