Stunnel证书被拒绝

Question

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

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

直到两天前它才停下来。

我安装了最新版本的STunnel，安装了以前工作过的conf，但是正在从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证书？

Answer 1

我也有过类似的问题：

> > 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”

我对原因没有任何解释。昨天之前一切都很正常。

祝你今天愉快。

克劳德·普罗

谢布鲁克，Qc，CA

Answer 2

这是来自Digicert的OCSP响应程序，它在过去的24小时内停止了对此证书的验证。我们经历了工作中的中断，因为我们有一个SSL检查设备，完全依赖于OCSP，而且检查是强制性的。今天早上4点左右，我们的服务台第一次报告了这一情况，但中断可能更早开始，因为我们至少将OCSP响应缓存了1天。

要验证这一点，您可以使用OpenSSL手动执行ocsp验证，或者使用第三方服务(例如：https://certificate.revocationcheck.com/outlook.com )。OCSP响应程序索引返回一个未经授权的错误(6)，用于任何试图对outlook的证书执行检查的人(outlook.office 365.com，outlook.live.com)。

我们试图联系赛门铁克和微软，但1级支持无法理解我在做什么。我只是浪费时间放弃了。最后，我刚刚给Digicert (support@digicert.com)发了电子邮件，尽管我们和他们没有合同，作为最后的手段。

最终，DigiCert的某个人会修好它.同时，您需要绕过OCSP检查(正如Claude以前建议的那样)，或者以某种方式配置OCSP检查以忽略无效的响应/错误。这并不总是可能的..。我不知道怎么用特技。