So I recently had a request to check out an SSL certificate error on one of our Apache servers.
The error was as follows:
This server could not prove that it is [redacted]; its security certificate is not trusted by your device’s operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
Further, the next error would be
Your connection is not private
Attackers might be trying to steal your information from [redacted] (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Odd, I thought. Because I had recently setup Apache on that server and tested it to work on Chrome (Mac), Chrome (Win), FireFox (Mac), FireFox (Win), and Safari (Mac).
Through further testing after this issue was brought to light, we found that this only happened on Chrome when on an Android-based operating system. Chrome on iOS, Windows, or Mac was not impacted.
I hate web browsers.
After muttering to myself about how web browser standards are anything but, I began troubleshooting.
Here is a snippet of how ssl.conf was configured on this Apache server while Chrome was getting the error:
Now, mycertificate.pem had both my web server SSL cert, my intermediate cert, and the root cert all packaged together nicely in one certificate file. This works in most cases, and has worked in the past for us — even on Android. But apparently now, through some change in the libraries used by Chrome on Android, or Chrome itself, or Android itself (who knows), this is no longer an acceptable approach.
So, I changed the ssl.conf to the following:
And now, things work as expected.
Do note, that all other browsers I have tested do accept this certificate bundling without pointing both directives to the same certificate bundle — including Chrome on iOS.