Tomcat 8.5 Alpine 3.5, openssl vs. libressl

[roadmapper]

Before OpenJDK changed the base image to Alpine 3.5, openssl (and therefore SSL/TLS connections) worked fine. Tomcat is now dependent on the latest upstream change from OpenJDK with Alpine 3.5 and libressl. This seems to break curl/Python client libraries attempting to connect to our Tomcat containers. I tried to build the Tomcat image myself with libressl in place of openssl, but that seems to fail on the native library building. Any thoughts on why this could be happening and ways to solve this problem?

[yosifkit]

We have seen problems of curl failing to verify certificates when run within alpine:3.5: docker-library/official-images#2756 (comment); maybe this is somehow related?

[roadmapper]

Yeah, I definitely think this is related. I ran very similar tests with curl/wget and got issues with ECDHE ciphers and SSL23_CLIENT_HELLO failures from curl, but on some machines was successful with non elliptic curve ciphers and on other machines (mostly non-libressl) successful connections. Was really not looking forward to moving back to the older OpenJDK Docker image since it won't be possible to update Java past 8u111.

I moved to Debian images for the time being, but the images are almost double in size 😕

Tomcat doesn't seem to support libressl properly either based on this bug in the Apache Tomcat bugzilla. I'll be following closely to your comment for that SonarQube PR. Hopefully someone has a solution.

[roadmapper]

Finally got around to testing if the changes in Alpine 3.6 with OpenJDK 8 b131 (r2); everything seems to work properly with elliptic curves now with the fix from alpinelinux/aports.