Stunnel 证书被拒绝

Stunnel cert rejected

不要问我为什么,我们的一位客户坚持使用虚拟访问作为电子邮件客户端。 (是的,2008 年的那个)

这需要 STunnel,因为它太蹩脚了,无法处理 SSL。

直到两天前它才停止工作。

我安装了最新版本的 STunnel,将之前相同的配置放入其中,但我收到来自 O365 的证书错误?

我的配置文件是:

    ; Sample stunnel configuration file for Win32 by Michal Trojnara 2002-2015
; Some options used here may be inadequate for your particular configuration
; This sample file does *not* represent stunnel.conf defaults
; Please consult the manual for detailed description of available options

; **************************************************************************
; * Global options                                                         *
; **************************************************************************

; Debugging stuff (may be useful for troubleshooting)
;debug = info
;output = stunnel.log

; Enable FIPS 140-2 mode if needed for compliance
;fips = yes

; Microsoft CryptoAPI engine allows for authentication with private keys
; stored in the Windows certificate store
; Each section using this feature also needs the "engineId = capi" option
;engine = capi

; **************************************************************************
; * Service defaults may also be specified in individual service sections  *
; **************************************************************************

; Enable support for the insecure SSLv3 protocol
;options = -NO_SSLv3

; These options provide additional security at some performance degradation
;options = SINGLE_ECDH_USE
;options = SINGLE_DH_USE

; **************************************************************************
; * Include all configuration file fragments from the specified folder     *
; **************************************************************************

;include = conf.d

; **************************************************************************
; * Service definitions (at least one service has to be defined)           *
; **************************************************************************

; ***************************************** Example TLS client mode services

[gmail-pop3]
client = yes
accept = 127.0.0.1:110
connect = outlook.office365.com:995
verifyChain = yes
CAfile = ca-certs.pem
checkHost = outlook.office365.com
OCSPaia = yes

[gmail-imap]
client = yes
accept = 127.0.0.1:143
connect = imap.gmail.com:993
verifyChain = yes
CAfile = ca-certs.pem
checkHost = imap.gmail.com
OCSPaia = yes

[gmail-smtp]
client = yes
accept = 127.0.0.1:25
connect = smtp.office365.com:587
verifyChain = yes
CAfile = ca-certs.pem
checkHost = smtp.office365.com
OCSPaia = yes
protocol = smtp

; Encrypted HTTP proxy authenticated with a client certificate
; located in the Windows certificate store
;[example-proxy]
;client = yes
;accept = 127.0.0.1:8080
;connect = example.com:8443
;engineId = capi

; ***************************************** Example TLS server mode services

;[pop3s]
;accept  = 995
;connect = 110
;cert = stunnel.pem

;[imaps]
;accept  = 993
;connect = 143
;cert = stunnel.pem

;[ssmtp]
;accept  = 465
;connect = 25
;cert = stunnel.pem

; TLS front-end to a web server
;[https]
;accept  = 443
;connect = 80
;cert = stunnel.pem
; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
;TIMEOUTclose = 0

; Remote cmd.exe protected with PSK-authenticated TLS
; Create "secrets.txt" containing IDENTITY:KEY pairs
;[cmd]
;accept = 1337
;exec = c:\windows\system32\cmd.exe
;execArgs = cmd.exe
;ciphers = PSK
;PSKsecrets = secrets.txt

; vim:ft=dosini

STunnel 日志中的错误是:

2018.11.09 17:26:47 LOG5[main]: stunnel 5.49 on x86-pc-msvc-1500 platform
2018.11.09 17:26:47 LOG5[main]: Compiled/running with OpenSSL 1.0.2p-fips  14 Aug 2018
2018.11.09 17:26:47 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
2018.11.09 17:26:47 LOG5[main]: Reading configuration from file stunnel.conf
2018.11.09 17:26:47 LOG5[main]: UTF-8 byte order mark detected
2018.11.09 17:26:47 LOG5[main]: FIPS mode disabled
2018.11.09 17:26:47 LOG5[main]: Configuration successful
2018.11.09 17:27:05 LOG5[0]: Service [gmail-pop3] accepted connection from 127.0.0.1:50953
2018.11.09 17:27:05 LOG5[1]: Service [gmail-smtp] accepted connection from 127.0.0.1:50954
2018.11.09 17:27:05 LOG5[1]: s_connect: connected 52.97.133.226:587
2018.11.09 17:27:05 LOG5[1]: Service [gmail-smtp] connected remote server from 192.168.16.222:50956
2018.11.09 17:27:05 LOG5[0]: s_connect: connected 52.97.133.226:995
2018.11.09 17:27:05 LOG5[0]: Service [gmail-pop3] connected remote server from 192.168.16.222:50955
2018.11.09 17:27:05 LOG5[0]: OCSP: Connecting the AIA responder "http://ocsp.digicert.com"
2018.11.09 17:27:05 LOG5[0]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:05 LOG5[0]: OCSP: Certificate accepted
2018.11.09 17:27:05 LOG5[0]: OCSP: Connecting the AIA responder "http://ocspx.digicert.com"
2018.11.09 17:27:05 LOG5[1]: OCSP: Connecting the AIA responder "http://ocsp.digicert.com"
2018.11.09 17:27:05 LOG5[0]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:05 LOG5[1]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:05 LOG3[0]: OCSP: Responder error: 6: unauthorized
2018.11.09 17:27:05 LOG4[0]: Rejected by OCSP at depth=0: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=outlook.com
2018.11.09 17:27:05 LOG3[0]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2018.11.09 17:27:05 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2018.11.09 17:27:05 LOG5[1]: OCSP: Certificate accepted
2018.11.09 17:27:05 LOG5[1]: OCSP: Connecting the AIA responder "http://ocspx.digicert.com"
2018.11.09 17:27:05 LOG5[1]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:05 LOG3[1]: OCSP: Responder error: 6: unauthorized
2018.11.09 17:27:05 LOG4[1]: Rejected by OCSP at depth=0: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=outlook.com
2018.11.09 17:27:05 LOG3[1]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2018.11.09 17:27:05 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2018.11.09 17:27:09 LOG5[2]: Service [gmail-pop3] accepted connection from 127.0.0.1:50962
2018.11.09 17:27:09 LOG5[3]: Service [gmail-smtp] accepted connection from 127.0.0.1:50963
2018.11.09 17:27:09 LOG5[2]: s_connect: connected 52.97.133.226:995
2018.11.09 17:27:09 LOG5[2]: Service [gmail-pop3] connected remote server from 192.168.16.222:50964
2018.11.09 17:27:09 LOG5[3]: s_connect: connected 52.97.133.226:587
2018.11.09 17:27:09 LOG5[3]: Service [gmail-smtp] connected remote server from 192.168.16.222:50965
2018.11.09 17:27:09 LOG5[2]: OCSP: Connecting the AIA responder "http://ocsp.digicert.com"
2018.11.09 17:27:09 LOG5[2]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:09 LOG5[2]: OCSP: Certificate accepted
2018.11.09 17:27:09 LOG5[2]: OCSP: Connecting the AIA responder "http://ocspx.digicert.com"
2018.11.09 17:27:09 LOG5[2]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:09 LOG5[3]: OCSP: Connecting the AIA responder "http://ocsp.digicert.com"
2018.11.09 17:27:09 LOG3[2]: OCSP: Responder error: 6: unauthorized
2018.11.09 17:27:09 LOG4[2]: Rejected by OCSP at depth=0: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=outlook.com
2018.11.09 17:27:09 LOG3[2]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2018.11.09 17:27:09 LOG5[2]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2018.11.09 17:27:09 LOG5[3]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:09 LOG5[3]: OCSP: Certificate accepted
2018.11.09 17:27:09 LOG5[3]: OCSP: Connecting the AIA responder "http://ocspx.digicert.com"
2018.11.09 17:27:09 LOG5[3]: s_connect: connected 93.184.220.29:80
2018.11.09 17:27:09 LOG3[3]: OCSP: Responder error: 6: unauthorized
2018.11.09 17:27:09 LOG4[3]: Rejected by OCSP at depth=0: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=outlook.com
2018.11.09 17:27:09 LOG3[3]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2018.11.09 17:27:09 LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket    

我只是在创建证书时遵循了 GUI,并在选择方面尽我所能。它确实创建了证书,但被拒绝了?

我需要为它提供 O365 SSL 证书吗?

我遇到了类似的问题:

> > 2018.11.09 12:52:18 LOG6[0]: CERT: Host name "outlook.office365.com" matched with "*.office365.com"
> 2018.11.09 12:52:18 LOG5[0]: OCSP: Connecting the AIA responder "http://ocspx.digicert.com"
> 2018.11.09 12:52:18 LOG6[0]: s_connect: connecting 72.21.91.29:80
> 2018.11.09 12:52:18 LOG7[0]: s_connect: s_poll_wait 72.21.91.29:80: waiting 10 seconds
> 2018.11.09 12:52:18 LOG5[0]: s_connect: connected 72.21.91.29:80
> 2018.11.09 12:52:18 LOG7[0]: OCSP: Connected ocspx.digicert.com:80
> 2018.11.09 12:52:18 LOG7[0]: OCSP: Response received
> 2018.11.09 12:52:18 LOG3[0]: OCSP: Responder error: 6: unauthorized
> 2018.11.09 12:52:18 LOG4[0]: Rejected by OCSP at depth=0: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=outlook.com
> 2018.11.09 12:52:18 LOG7[0]: TLS alert (write): fatal: handshake failure
> 2018.11.09 12:52:18 LOG3[0]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

我的解决方案:

在 stunnel.conf 中将 "OCSPaia = yes" 更改为 "OCSPaia = no"

我没有关于原因的解释。直到昨天一切正常。

祝你有美好的一天。

克劳德·普罗托

加利福尼亚州舍布鲁克

这是来自 Digicert 的 OCSP 响应程序,它在过去 24 小时内停止验证此证书。我们在工作中遇到了中断,因为我们有一个完全依赖 OCSP 的 SSL 检查设备,并且检查是强制性的。今天早上美国东部标准时间凌晨 4 点左右,我们的服务台首次报告了该问题,但中断可能开始得更早,因为我们至少将 OCSP 响应缓存了 1 天。

要自行验证,您可以使用 OpenSSL 手动执行 ocsp 验证,或使用第三方服务(例如:https://certificate.revocationcheck.com/outlook.com)。 OCSP 响应程序确实 return 一个错误,未授权 (6),对于任何试图检查 outlook 证书的人 (outlook.office365.com, outlook.live.com).

我们尝试联系 Symantec 和 Microsoft,但 1 级支持无法理解我的意思。我只是浪费了时间而放弃了。最后,作为最后的手段,我只是给 Digicert (support@digicert.com) 发了邮件,尽管我们没有与他们签订合同。

最终,DigiCert 的某个人会修复它...与此同时,您需要绕过 OCSP 检查(如 Claude 之前所建议的),或者以某种方式配置 OCSP 检查以忽略无效 responses/errors .这并不总是可能的......我不知道如何用 stunnel 做到这一点。