httpd 服務器上的 ERR_BAD_SSL_CLIENT_AUTH_CERT 問題

Question

I have an application running on httpd server under Centos 8. The Apache server requires user to show vaild certificate and than the ssl variables like DN, CN and SERIAL are passed to the Flask application (than the access verification is run). 當應用程序提供無效證書時，例如用戶的證書不在數據庫中，應在 url "/site/public/failed" 下顯示錯誤頁面，並提供適當的信息。 問題是只有我的證書通過了 Apache 並且頁面加載正確（我的證書在 db 中），但是當我的拼貼畫（同一家公司，同一 CA）嘗試訪問它時，它們會閃爍 ERR_BAD_SSL_CLIENT_AUTH_CERT 和空白頁。 我假設即使他們將在數據庫中，Apache 也不會讓他們訪問上面的應用程序。 當我在他們嘗試連接后檢查日志時，它看起來與我連接時不同。 我發現的一件事是，當我進入深度 2 時，僅使用深度 0 檢查他們的證書。配置：

Listen ip:443
##SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
##SSLCipherSuite PROFILE=SYSTEM
##SSLCipherSuite  ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
##SSLCipherSuite 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:!DES:!RC4:!3DES:!MD5:!PSK
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
SSLHonorCipherOrder on
SSLCompression off


WSGIPythonHome /home/path/to/venv
WSGIRestrictStdin Off
WSGIRestrictStdout Off
<VirtualHost ip:443>
        ServerName      app.com
        ErrorLog        /etc/httpd/logs/sshproxy-secure.error_log
        CustomLog       /etc/httpd/logs/sshproxy-secure.access_log ssl_combined

        SSLEngine on
        SSLCertificateFile      /home/path/to/crt.crt
        SSLCertificateKeyFile   /home/path/to/some_key.key
        SSLCACertificateFile /etc/pki/tls/main_ca.crt
        SSLCACertificateFile /path/to/more/ca.crt

        WSGIDaemonProcess sshproxy threads=20 processes=2 python-path=/home/path/to/venv/lib/python3.10/site-packages
        #user=user1 group=group1 threads=5
        #WSGIPythonPath /opt/sshproxy/lib/python2.7/site-packages
        WSGIScriptAlias / /home/path/to/wsgi-script/sshproxy-webserver-wsgi.py
        WSGIScriptReloading On

    <Directory /home/path/to/app>
        WSGIProcessGroup sshproxy
        WSGIApplicationGroup %{GLOBAL}
        Require all granted
    </Directory>

     #<Location />
     #   SSLRequireSSL
        #Require ip 126.16.13.20 126.16.18.
     #</Location>
        SSLVerifyClient optional
        SSLVerifyDepth 5
        SSLOptions +StdEnvVars
</VirtualHost>

連接時的錯誤日志（我刪除了一些敏感數據，但我認為它不是日志的重要部分）：

[Mon Aug 29 08:36:54.406586 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2330): [client 126.189.244.168:60496] AH02043: SSL virtual host for servername app.com found
[Mon Aug 29 08:36:54.406615 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2330): [client 126.189.244.168:60496] AH02043: SSL virtual host for servername app.com found
[Mon Aug 29 08:36:54.406629 2022] [core:debug] [pid 17586:tid 140176105887488] protocol.c(2314): [client 126.189.244.168:60496] AH03155: select protocol from , choices=h2,http/1.1 for server app.com
[Mon Aug 29 08:36:59.631867 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 2, CRL checking mode: none (0) [subject: 
[Mon Aug 29 08:36:59.632161 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 1, CRL checking mode: none (0) [subject: 
[Mon Aug 29 08:36:59.632380 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 0, CRL checking mode: none (0) [subject: 
[Mon Aug 29 08:36:59.632679 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2246): [client 126.189.244.168:60496] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_128_GCM_SHA256 (128/128 bits)
[Mon Aug 29 08:36:59.633566 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(383): [client 126.189.244.168:60496] AH02034: Initial (No.1) HTTPS request received for child 204 (server domain:443)
[Mon Aug 29 08:36:59.633893 2022] [authz_core:debug] [pid 17586:tid 140176105887488] mod_authz_core.c(820): [client 126.189.244.168:60496] AH01626: authorization result of Require all granted: granted
[Mon Aug 29 08:36:59.633925 2022] [authz_core:debug] [pid 17586:tid 140176105887488] mod_authz_core.c(820): [client 126.189.244.168:60496] AH01626: authorization result of <RequireAny>: granted

連接時的錯誤日志：

[Tue Aug 30 11:01:41.293387 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(2330): [client 126.189.44.235:57122] AH02043: SSL virtual host for app.com
[Tue Aug 30 11:01:41.293496 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(2330): [client 126.189.44.235:57122] AH02043: SSL virtual host for app.com
[Tue Aug 30 11:01:41.293519 2022] [core:debug] [pid 24609:tid 140421665646336] protocol.c(2314): [client 126.189.44.235:57122] AH03155: select protocol from , choices=h2,http/1.1 for server
[Tue Aug 30 11:01:41.476727 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(1751): [client 126.189.44.235:57122] AH02275: Certificate Verification, depth 0, CRL checking m
[Tue Aug 30 11:01:41.476860 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH02276: Certificate Verification: Error (66): EE certificate key too weak [subject: e
[Tue Aug 30 11:01:41.476988 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH02008: SSL library error 1 in handshake (server domain:443)
[Tue Aug 30 11:01:41.477100 2022] [ssl:info] [pid 24609:tid 140421665646336] SSL Library Error: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
[Tue Aug 30 11:01:41.477120 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH01998: Connection closed to child 194 with abortive shutdown (server napupp19.corpne
[Tue Aug 30 11:01:44.545107 2022] [ssl:info] [pid 24609:tid 140421573326592] [client 126.189.44.235:57125] AH01964: Connection to child 205 established (server domain:443)
[Tue Aug 30 11:01:44.545572 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(532): AH00835: socache_shmcb_retrieve (0xea -> subcache 10)
[Tue Aug 30 11:01:44.545621 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(917): AH00851: shmcb_subcache_retrieve found no match
[Tue Aug 30 11:01:44.545634 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(542): AH00836: leaving socache_shmcb_retrieve successfully

我不知道他們的證書從深度 0 開始檢查的原因是什么，而我的證書是從深度 2 開始檢查的？

Answer 1

將 openssl.cnf 文件中的cipher string = default@seclevel=2更改為cipher string = default@seclevel=1已解決問題。 盡管如此，我不知道為什么我的證書通過而其他人沒有。 我們都有帶證書的標准化令牌，因此它們都應該具有相似的 sec 級別。