Stunnel cert rejected

Question

Don't ask me why but a customer of ours insists on using Virtual Access as an email client. (yes, the very old one from 2008)

This requires STunnel as it's so lame it doesn't handle SSL.

It had been working fine until two days ago when it just stopped.

I installed the latest version of STunnel, put the same previously working conf in, but am getting certificate errors from O365?

My config file is:

    ; 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

The errors in the STunnel log are:

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    

I just followed the GUI when creating the cert and put the best thing I could in with regards to the choices. It did create the cert but it's being rejected?

Do I need to supply it with the O365 SSL cert?

Answer 1

I had a similar problem:

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

My solution:

In stunnel.conf change "OCSPaia = yes" to "OCSPaia = no"

I do not have an explanation on the cause. Everything was working until yesterday.

Have a good day.

Claude Proteau

Sherbrooke, Qc, CA

Answer 2

This is the OCSP responder from Digicert that stopped validating this certificate in the last 24hours. We experienced an outage at work because we have an SSL inspection device that rely exclusively on OCSP, and the check is mandatory. It was first reported at our service desk around 4am EST this morning, but the outage may have started earlier, because we cache the OCSP responses for 1 day at least.

To validate this on your own, you can perform an ocsp validation manually using OpenSSL, or use a third party service (eg: https://certificate.revocationcheck.com/outlook.com ). The OCSP responder indeeds return an error, Unauthorized(6), for anyone trying to perform a check on outlook's certificate (outlook.office365.com, outlook.live.com).

We tried to contact Symantec, and Microsoft, but level 1 support could not understand what I was taking about. I just wasted my time and gave up. Finally, I just emailed Digicert ([email protected]), even though we have no contract with them, as a last resort.

Eventually, someone at DigiCert will fix it... In the meantime, you need to bypass the OCSP check (as suggested by Claude previously), or somehow, configure the OCSP checks to ignore invalid responses/errors. Which isn't always possible... I wouldn't know how to do that with stunnel.