-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Importing Ca certificates with USE_SYSTEM_CA_CERTS is slower than it used to be #612
Comments
This is likely due to the bump from alpine:3.19 to alpine:3.20. I'll do some digging and see if something needs changing |
ping @rassie incase you have any ideas what might be going on here |
From what I can see at the first glance, @achimwinter can you give us the exact image versions you are using, i.e. working and breaking? Thanks. |
Having dug around a bit, I think it's the changed algorithm around importing certificates. I'll try to figure out what to change and would add the fix to #572 or maybe a separate PR. |
Sure 21.0.3_9-jre-alpine is definitely working for me. And i think i even tried it with 21-ubi9-minimal, but i would need to make sure of that. I also saw, that all these info statements at the beginning were also the like EDIT: I can confirm that the same error applies to e.g. 21.0.4_7-jre-ubi9-minimal which seems in line with the algorithm being the issue |
Just for the record: the reason is that the previous algorithm generated system certificates with |
Thanks for looking into this. Can you make sure that we add a test to prevent this being broken again in the future? |
@achimwinter @rassie has prepared a fix, we'll get his changes merged and roll out a new release. |
keeping this open until we've confirmed a fix. The images will be updated once docker-library/official-images#17249 is merged |
@achimwinter can you please confirm if this is fixed now? |
Yes, it works again 👍 However one thing i should mention is that the certificate import needs now about 2-3 minutes on container start. |
I had the same problem. The fix works, but running __cacert_entrypoint.sh again results in a failure of the script with a exit code of 1.
I am using eclipse-temurin:17-jdk-alpine |
@rassie I'm also looking into this but do you have any idea why this might be so much slower? Could it be the csplit command? |
This reverts the new cacert update script, which leads to errors when restarting a container. See also: adoptium/containers#612
This reverts the new cacert update script, which leads to errors when restarting a container. See also: adoptium/containers#612
This reverts the new cacert update script, which leads to errors when restarting a container. See also: adoptium/containers#612
I believe I am running into a similar issue. Since using the latest 'eclipse-temurin:21-jdk' image it works initially but restarting the container results in a lot of 'Entry for alias ... successfully imported.' and then never continues to boot our spring boot application using java -jar as specified in the command, the container exits instead. I'm unable to find a changelog that describes what we have to change to keep our cartificate import working like it did in image |
Please add the exact image (with tag) that you are using
21-jre-alpine
Please add the version of Docker you are running
Docker version 26.1.3, build b72abbb
What happened?
Since yesterday (23.07.2024) i get a exception connecting to my documentDB Database on AWS.
My setup is like this: in a builder stage i download the
global-bundle.pem
from aws and copy that to/certificates/aws-ca.crt
.Setting the Environment variable
ENV USE_SYSTEM_CA_CERTS=1
Which worked for me so far, except for images from yesterday on.
Since then i get a whole lot of log statements in the container about all the certificates imported, but the application fails when connecting to the database.
I also tried to use: "JRE_CACERTS_PATH" (from https://github.com/docker-library/docs/pull/2445/files) added to the CMD, but that also didnt work. (I am not using a non-root image)
Using an older image works still fine.
Relevant log output
The text was updated successfully, but these errors were encountered: