不要问我为什么，但是我们的客户坚持使用Virtual Access作为电子邮件客户端。 （是的，那是2008年的旧款）
这需要STunnel，因为它很la脚，无法处理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证书吗？
答案 0 :(得分：0)
我有一个类似的问题：
> > 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”
我没有原因的解释。一切都一直进行到昨天。
祝你有美好的一天。
克洛德（Claude Proteau）
加利福尼亚州Qc，Sherbrooke
答案 1 :(得分：0)
这是Digicert的OCSP响应者，它在最近24小时内停止验证此证书。我们在工作中遇到了停机，这是因为我们有一个完全依赖OCSP的SSL检查设备，并且必须进行检查。最早是在今天上午EST 4左右在我们的服务台上报告的，但是中断可能是较早开始的，因为我们至少将OCSP响应存储了1天。
要自行验证，可以使用OpenSSL手动执行ocsp验证，或使用第三方服务（例如：https://certificate.revocationcheck.com/outlook.com）。对于尝试对Outlook的证书（outlook.office365.com，outlook.live.com）进行检查的任何人，OCSP响应者的确会返回错误Unauthorized（6）。
我们试图与Symantec和Microsoft联系，但是1级支持无法理解我的打算。我只是浪费时间放弃了。最后，尽管我们没有与Digicert签约，但我还是发了电子邮件给Digicert（support@digicert.com）。
最终，DigiCert的某个人将对其进行修复...同时，您需要绕过OCSP检查（如之前Claude的建议），或者以某种方式配置OCSP检查以忽略无效的响应/错误。这并不总是可能的...我不知道该如何使用stunnel。