apache httpd服务器上的ERR_BAD_SSL_CLIENT_AUTH_CERT出现问题

prdp8dxp  于 2022-11-16  发布在  Apache
关注(0)|答案(1)|浏览(1805)

我在Centos 8下的httpd服务器上运行了一个应用程序。Apache服务器要求用户显示有效证书,然后将诸如DN、CN和SERIAL等ssl变量传递给Flask应用程序(然后运行访问验证)。应用程序在提供的证书无效时(例如,用户的证书不在数据库中),我应该在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开始检查?

dpiehjr4

dpiehjr41#

在openssl.cnf文件中将cipher string = default@seclevel=2改为cipher string = default@seclevel=1解决了这个问题。但是我不知道为什么我的证书被通过了,而其他人没有。我们都有标准化的令牌和证书,所以他们都应该有类似的sec级别。

相关问题