Я переношу сервер под управлением Debian 10 на сервер под управлением Debian 12 (и ядра 6.x), и последнее, что, похоже, не работает, — это TLS 1.0, с которым я пытаюсь разобраться.
Я знаю об изменении SECLEVELиMinProtocol как описано здесь:https://stackoverflow.com/a/61568390/6110631, но по какой-то причине это не сработало.
В рабочей системе у меня есть:
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL:@SECLEVEL=1
Я попробовал добавить это таким же образом на новой системе, но TLS 1.0 все еще не работает. На сервере Apache (который является зависимым приложением) я вижу:
AH02039: Certificate Verification: Error (68): CA signature digest algorithm too weak
Я в какой-то степени ожидал этого, так как я полагал, что TLS 1.0 будет отключен по умолчанию, поэтому я продолжил играть с конфигурацией. Никакие внесенные мной изменения, похоже, не сработали, и, выполняя захват пакетов с точки зрения клиента через зеркало порта, я мог видеть, что все согласования TLS полностью провалились (сразу после Client Hello, Alert (Level: Fatal, Description: Protocol Version).
При проверке с помощью openssl s_clientTLS 1.0, похоже, что-то в нем серьезно сломалось.
На существующем сервере Debian 10 я получаю:
# openssl version
OpenSSL 1.1.1n 15 Mar 2022
# openssl s_client -connect OLDHOST -tls1
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = OLDHOST
verify return:1
---
Certificate chain
0 s:CN = OLDHOST
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Однако на новом сервере Debian 12 я получаю:
# openssl version
OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
# openssl s_client -connect NEWHOST -tls1
CONNECTED(00000003)
140101680407744:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 136 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1695085443
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
TLS 1.2 по-прежнему работает правильно, но вот эта проблема возникает при использовании TLS 1.0 и TLS 1.1.
Я пробовал использовать DEFAULT:@SECLEVEL=1и ALL:@SECLEVEL=1другие комбинации sec level 1, sec level 0, ALL, DEFAULT, LEGACY и т. д. Ни одна из них не работает. Я регулярно перезапускал Apache и весь сервер между изменениями.
Я также попробовал добавить это в конфигурацию Apache, и теперь у меня следующее:
Protocols h2 http/1.1
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL:@SECLEVEL=0
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
Другие связанные вопросы/ответы, которые, к сожалению, не дали никакой дополнительной информации:
SECLEVELВ некоторых местах, похоже, подразумевается, что в настоящее время для того, чтобы это заработало, необходимо понизить значение с 1 до 0, например, для сертификатов SHA1, что я и сделал, но сигары по-прежнему нет.
Поддержка TLS 1.0 и 1.1 естьнетбыл удален в OpenSSL 3 (я проверял), поэтому должен поддерживаться при правильной настройке.
Все задокументированные решения, похоже, не работают для меня, и я, похоже, не приблизился ни на шаг после того, как потратил целый день на отладку этого. Есть ли еще какие-нибудь решения, которые кто-нибудь нашел, чтобы заставить работать старые шифры? Я указываю ALLшифры и на обоих уровнях 0 и 1, и, похоже, они мне не подчиняются, так что это кажется довольно странным.
решение1
Я знал, что это возможно, и, скорее всего, это просто ошибка конфигурации... так оно и было.
Установка SECLEVEL на 0 действительно необходима, но у меня это было во многих местах, и я не обновил его во всех из них.
В частности, конкретный виртуальный хост все еще имел SSLCipherSuite ALL:@SECLEVEL=1, который отлично работал со старыми версиями OpenSSL, но теперь его нужно изменить на SSLCipherSuite ALL:@SECLEVEL=0.
(Я установил это в общей конфигурации Apache, а также в /etc/ssl/openssl.cf`, но поскольку это было установлено на уровне виртуального хоста, это переопределяло его. Все остальные виртуальные хосты уже были на уровне 0, и я просто проводил тестирование, используя один виртуальный хост, который был переопределен на 1, естественно...)
Я хочу подчеркнуть, что люди, которые говорят, что TLS 1.0 не поддерживается последними ядрами, Apache или OpenSSL (например, в комментарии к этому вопросу),неправильныйи они работают справильныйконфигурация. Похоже, это распространенное заблуждение.
В настоящее время конечный клиент все еще не подключается (сбой подтверждения TLS), так что что-то еще не так, но openssl s_clientтеперь согласование происходит правильно, в отличие от предыдущего случая, что является прогрессом.
TheполныйРешение также заключалось в том, чтобы понять, что и certbot, и acme.sh по умолчанию теперь предпочитают ECDSA, и поэтому вам нужно явно запросить RSA, чтобы получить недостающие шифры. Старый сервер «работал» нормально, потому что сертификаты обновлялись одного и того же типа.
Фрагмент из openssl.cnfновой, работающей системы:
cat /etc/ssl/openssl.cnf | grep -v "#"
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL@SECLEVEL=0