Вопросы Теги

Обновите 16.04 LTS - 18.04 LTS - tls_process_client_certificate:certificate проверяют отказавший - при использовании PSS промежуточное звено Со знаком

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

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

Теперь мы обновили для использования HTTP2

Ubuntu 18.04.1 Apache LTS 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>

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

Клиентские сертификаты выпущены промежуточным CA, который является самостоятельно RSA-PSS, Со знаком. Корневой 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 intermediat Приблизительно. Это работает без проблем. Поскольку я подозреваю, что путем обновления Apache или openssl там теперь проблема с подписанными выпускающими PSS. У кого-то есть идея, что можно сделать, чтобы заставить его полететь снова?

1
задан 25 September 2018 в 12:07

2 ответа

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

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

1
ответ дан 7 December 2019 в 15:13

Можно теперь использовать Виа OpenSSL 1.1.1 TLSv1.3 через 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
0
ответ дан 7 December 2019 в 15:13

Другие вопросы по тегам:

Похожие вопросы: