Consider adding default certificate for GeoTrust Global CA

We updated our Docker base image from OpenJDK 11 to OpenJDK 14 and our push notifications stopped working, root cause being “sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target”.

I tested the same code on my Mac, also using OpenJDK 14, but everything worked correctly. Finally, I grabbed /usr/local/openjdk-14/lib/security/cacerts from the Docker image and started my test program using -Djavax.net.ssl.trustStore=$HOME/tmp/cacerts-java14 and got the failure to reproduce locally.

I started to study the problem and found out that OpenJDK, along with browser vendors, has disabled support for GeoTrust Global CA, which is the root CA used by api.push.apple.com:

• https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates
• https://groups.google.com/a/chromium.org/g/blink-dev/c/eUAKwjihhBs/m/El1mH8S6AwAJ?pli=1
• https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

However, the browser vendors seem to have an exception for certificates signed by some known intermediary CAs (one being Apple’s CA). I saw no evidence of such exception on JDK. Also, it seems that MacOS is configured to trust Apple’s CA. Therefore, opening api.push.apple.com using a browser or default JDK settings on Mac works, but fails if JDK is instructed to only use $JAVA_HOME/lib/security/cacerts.

Apple’s APNS documentation has a note that tells one to make sure that GeoTrust_Global_CA.pem is trusted by the system. And sure enough: if we pass that to ApnsClientBuilder.setTrustedServerCertificateChain, everything works correctly.

This finally brings me to my issue: it’s certainly possible to configure Pushy to work with Apple’s APNS servers (I was so happy to find setTrustedServerCertificateChain which saved the day). And of course one could consider this to be an issue with JDK or the environment and not with Pushy. But since OpenJDK on Docker without any extra certificates is probably a pretty common deployment target for Pushy, I think more and more people will bump into this same issue. So it would be really nice is Pushy would just work out-of-the-box. Or if messing with the default certificates feels bad, perhaps the situation could be detected and Pushy could give an informative error message with a link to the documentation?

[jchambers]

Well, I’m embarrassed to say that I think the need for this has passed. Apple has, in my opinion, done basically the right thing, which is “use a widely-trusted certificate.” We may need something like this again in the future, but don’t think we do right now. I’m going to close this for now.

Thank you all for your feedback and thoughtful discussion; I’m sorry that this didn’t get out in time to be helpful to the community.

[jchambers]

…and for posterity, we started a discussion (our first github discussion!) for issues around this transition.

For us, the biggest issue was prematurely retiring the Geotrust certificate; it seems like the upstream servers are still bouncing back and forth between Geotrust and Comodo a bit (or were this morning, anyhow).

That said, my own experience dealing with this makes me think we need to try a different approach to the “add whatever certificates Apple needs” mechanism. I’m sketching out a prototype now to make sure it’s not ridiculous.