Обновление 16.04 LTS - 18.04 LTS - tls_process_client_certificate: сбой проверки сертификата - при использовании PSS-подписанного посредника

Мы используем конфигурацию Clientauth для местоположения без проблем в течение многих месяцев

Ubuntu 16.04.5 LTS Apache 2.4.18-2ubuntu3.9 openssl 1.0.2g-1ubuntu4.13

Теперь мы обновились, чтобы использовать HTTP2

Ubuntu 18.04.1 LTS Apache 2.4.29-1ubuntu4.3 Openssl 1.1.0g-2ubuntu4.1

Apache Conf:

 SSLEngine on
   SSLVerifyDepth 2
   SSLProxyEngine on
   SSLProtocol -All +TLSv1.2 +TLSv1.1

   SSLCipherSuite HIGH:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!EXP:!DES:!RC4:!3DES:!MD5:!PSK:!MEDIUM:!LOW:!SRP:!DSS

   SSLCertificateFile /etc/apache2/ssl/blablub.pem
   SSLCertificateKeyFile /etc/apache2/ssl/blablub.key
   SSLCertificateChainFile /etc/apache2/ssl/blablub.ca_certificates.pem
   SSLCACertificateFile /etc/apache2/ssl/ProductiveCAClientAuth.pem 

....other stuff without ClientAuth...

   <Location /test>
       SSLVerifyClient require
       SSLVerifyDepth 2

       ProxyPass https://server-1/test
       ProxyPassReverse https://server-1/testg

   </Location>

Особенность:

Сертификаты клиента выдаются промежуточным центром сертификации, который сам является RSA-PSS Signed. Корневой CA и действительные клиентские сертификаты обычно подписываются RSA-SHA256. Не спрашивайте почему, вот как это было построено в прошлом и до сих пор работало

Ошибка:

[Tue Sep 25 07:18:27.723798 2018] [ssl:debug] [pid 49219:tid 140033499584256] ssl_engine_kernel.c(757): [client 89.187.203.114:61120] AH02255: Changed client verification type will force renegotiation
[Tue Sep 25 07:18:27.723803 2018] [ssl:info] [pid 49219:tid 140033499584256] [client 89.187.203.114:61120] AH02221: Requesting connection re-negotiation
[Tue Sep 25 07:18:27.723827 2018] [ssl:debug] [pid 49219:tid 140033499584256] ssl_engine_kernel.c(987): [client 89.187.203.114:61120] AH02260: Performing full renegotiation: complete handshake protocol (client does support secu
re renegotiation)
[Tue Sep 25 07:18:27.723867 2018] [ssl:info] [pid 49219:tid 140033499584256] [client 89.187.203.114:61120] AH02226: Awaiting re-negotiation handshake
[Tue Sep 25 07:18:33.176966 2018] [ssl:error] [pid 49219:tid 140033499584256] [client 89.187.203.114:61120] AH02261: Re-negotiation handshake failed
[Tue Sep 25 07:18:33.176987 2018] [ssl:error] [pid 49219:tid 140033499584256] SSL Library Error: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
[Tue Sep 25 07:18:33.177005 2018] [core:trace3] [pid 49219:tid 140033499584256] request.c(119): [client 89.187.203.114:61120] auth phase 'check access (with Satisfy All)' gave status 403: /test/
[Tue Sep 25 07:18:33.177032 2018] [headers:debug] [pid 49219:tid 140033499584256] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()
[Tue Sep 25 07:18:33.177057 2018] [http:trace3] [pid 49219:tid 140033499584256] http_filters.c(1128): [client 89.187.203.114:61120] Response sent with status 403, headers:
[Tue Sep 25 07:18:33.177062 2018] [http:trace5] [pid 49219:tid 140033499584256] http_filters.c(1135): [client 89.187.203.114:61120]   Date: Tue, 25 Sep 2018 05:18:27 GMT
[Tue Sep 25 07:18:33.177066 2018] [http:trace5] [pid 49219:tid 140033499584256] http_filters.c(1138): [client 89.187.203.114:61120]   Server: Apache/2.4.34 (Ubuntu)
[Tue Sep 25 07:18:33.177071 2018] [http:trace4] [pid 49219:tid 140033499584256] http_filters.c(957): [client 89.187.203.114:61120]   X-Frame-Options: SAMEORIGIN
[Tue Sep 25 07:18:33.177075 2018] [http:trace4] [pid 49219:tid 140033499584256] http_filters.c(957): [client 89.187.203.114:61120]   Content-Length: 320
[Tue Sep 25 07:18:33.177080 2018] [http:trace4] [pid 49219:tid 140033499584256] http_filters.c(957): [client 89.187.203.114:61120]   Connection: close
[Tue Sep 25 07:18:33.177084 2018] [http:trace4] [pid 49219:tid 140033499584256] http_filters.c(957): [client 89.187.203.114:61120]   Content-Type: text/html; charset=iso-8859-1

Мы снова проверили все это с помощью клиентских сертификатов, выданных промежуточным центром сертификации SHA256. Это работает без проблем. Поскольку я подозреваю, что при обновлении Apache или openssl теперь существует проблема с подписчиками PSS. У кого-то есть идея, что вы можете сделать, чтобы он снова полетел?

Источник

2 ответа

Основная проблема решена с обновлением до OpenSSL 1.1.1 Хотя проблема решена и ClientAuth снова работает, но это очень медленно. Обычный вход в систему теперь занимает 60-120 секунд. Также не помогло обновление до Apache 2.4.35. Различных тестов с настройками SSLCache у Apache тоже нет.

Я думаю, что поскольку Apache официально не поддерживает openSSL 1.1.1 и TLS 1.3, он просто помогает подождать, пока он официально не будет поддержан.

Источник

Теперь вы можете использовать TLSv1.3 через OpenSSL 1.1.1 через Ondrej Sury PPA для apache2 (или nginx), добавив свой репозиторий для apache2 (или nginx), затем удалите по умолчанию apache2 (измените apache2 на nginx, если вы используете более позднюю версию) и переустановите следующее:

apache2 and openssl 1.1.1:
add-apt-repository ppa:ondrej/apache2
apt-get update
apt-get -y remove apache2
apt-get -y install apache2 openssl
Источник
Другие вопросы по тегам