Add documentation for custom CA certificates for Temurin

[rassie]

Will be available after adoptium/containers#392 is merged.

[tianon]

Oof, I don't love the feature, but I don't think I dislike it strongly enough to block it at the official images level. 😬

(It feels like scope creep IMO, since it's something users would generally want from "any" container, but it's not super reasonable for every container to implement this type of entrypoint behavior, and it certainly isn't likely to be implemented in debian, alpine, etc. 😅)

[rassie]

FWIW, it's a feature that has been available in the old openjdk images for a long time. Adding CA certificates in general to the OS's certificate store hasn't been a problem, it's all about Java's truststore, so I think I can't agree on the "scope creep" part. Either way, thanks for not blocking :)

[tianon]

Not like this, no - the only part that was in openjdk was making sure that if the system CA store was updated, that the Java store was kept in sync. There wasn't any functionality there to automatically import user-provided certs (I wrote the code for it 😅).

[tianon]

(ie, there was never an ENTRYPOINT defined in the openjdk images, and this is introducing one in eclipse-temurin that I imagine is not necessarily desirable for a lot of the images downstream from this that might define their own entrypoint scripts)

[rassie]

(ie, there was never an ENTRYPOINT defined in the openjdk images, and this is introducing one in eclipse-temurin that I imagine is not necessarily desirable for a lot of the images downstream from this that might define their own entrypoint scripts)

Yeah, I've hoped we could avoid introducing the entrypoint script, but with ubi9 there was simply no way to add an update-ca-certificates-style hook like in openjdk. Best I could do is make the entrypoint a noop in "normal" circumstances, that's why there is an opt-in variable, which also means that nothing changes for those downstream images.

(on a more self-centered note, the entrypoint solves a quite large pain point for us -- with openjdk we needed to overwrite the entrypoint with bash -c "update-ca-certificatest; <whatever the original entrypoint did>", which varied depending on the image, i.e. if the product teams changed the invocation (e.g. from java -jar product-fatjar.jar to java org.springframework.boot.loader.JarLauncher), we had to synchronize that with deployment scripts)

[tellison]

Just noting that the implementation has been merged, so this documentation issue can continue.

[gdams]

@tianon please can we get this merged

[yosifkit]

Close/open in attempt to get tests to run.

[yosifkit]

I had to copy the test output to see it, but there is an extra whitespace at the end of line that markdownfmt is complaining about.

diff ./eclipse-temurin/content.md markdownfmt/./eclipse-temurin/content.md
--- /tmp/markdownfmt1406235651
+++ /tmp/markdownfmt2757242851
@@ -14,13 +14,13 @@
 
 # Can I add my internal CA certificates to the truststore?
 
-Yes! Add your certificates to `/certificates` inside the container (e.g. by using a volume) and set the environment variable `USE_SYSTEM_CA_CERTS` on the container to any value. With Docker CLI this might look like this: 
+Yes! Add your certificates to `/certificates` inside the container (e.g. by using a volume) and set the environment variable `USE_SYSTEM_CA_CERTS` on the container to any value. With Docker CLI this might look like this:
 
 ```console
 $ docker run -v $(pwd)/certs:/certificates/ -e USE_SYSTEM_CA_CERTS=1 %%IMAGE%%:11 
 ```
 
-The certificates would get added to the system CA store, which would in turn be converted to Java's truststore. The format of the certificates depends on what the OS of the base image used expects, but PEM format with a `.crt` file extension is a good bet. **Please note**: this feature is currently not available for Windows-based images. 
+The certificates would get added to the system CA store, which would in turn be converted to Java's truststore. The format of the certificates depends on what the OS of the base image used expects, but PEM format with a `.crt` file extension is a good bet. **Please note**: this feature is currently not available for Windows-based images.

[rassie]

Let me take a look at it tomorrow and rebase it while we are it.

[rassie]

I've rebased on current master branch, fixed Markdown so that .ci/check-markdownfmt.sh doesn't complain anymore and squashed the commits. Should be good to go (fingers crossed).