ERR_SSL_BAD_RECORD_MAC_ALERT

3,652 views
Skip to first unread message

stefan.b...@prosteps.be

unread,
Feb 27, 2018, 4:36:25 AM2/27/18
to Google Chrome Developer Tools
Hi All,

We have a Windows application which is running an HTTP(S) server that is installed by our customers as a gateway between the web application and specific hardware.
Until now all traffic was HTTP and we are in the transition to HTTPS.

During dev and initial testing everything worked fine.
However during the pilot roll-out at one of our customers several stations (approx 1/3) reported the "ERR_SSL_BAD_RECORD_MAC_ALERT" in Google Chrome.

After several hours of debugging and testing I can say that the issue exists in all Chromium based browsers.
I also tested with IE, EDGE and Firefox and they work fine.

I tested  several versions of Google Chrome V59 - 64.


The certficate used is a wildcard certificate from Comodo valid until Nov 2020.
The HTTPS server supports SSL3, TLS1.0, 1.1, 1.2 with all ciphers



Can someone push me in the direction of locating and fixing this problem?


I'm sure you need more details than what is stated above, but I have no clue which so please ask and I will provide!


Many thanks in advance,
Stefan

stefan.b...@prosteps.be

unread,
Feb 28, 2018, 5:56:27 AM2/28/18
to Google Chrome Developer Tools
Until now we were using the SecureBlackBox component set in our application the setup the HTTPS server.
I created a test application with the OpenSSL library instead and that seems to be working fine on a previously faulty computer.

So at this point I would say that it is a faulty component we are using but then again, why only on several stations and not all...


Larry LACa

unread,
Feb 28, 2018, 3:53:13 PM2/28/18
to Google Chrome Developer Tools
Thanks for the followup, glad you found a solution. 

Chrome gets part of it's Windows network services from the OS and part is customized - hence the differences between the browsers.

The Chrome code is highly optimized, including the SSL layer, and under constant development and repair.  It's not surprising that one package performs slightly different than another.  I'm more impressed that the interface definitions are stable enough that the packages all work almost all the time.

If the SecureBlackBox failure was consistently reproducible, even at a 30% failure rate, you could followup with the vendor.  They may just need to update for the latest Chrome usage.

The about:net-export and net-internals provide debug tracing if you want to dig into it. 

In general, this forum focuses only on dev-console issues.  App dev issues get more attention elsewhere, like StackOverflow.  The Security-dev forum is also a good place to look.
Reply all
Reply to author
Forward
0 new messages