Closed nudgegoonies closed 4 years ago
Sorry, I don't follow. How does the problem manifest?
When I try to install adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb
, it is installed before ca-certificates-java
and the keystore /etc/ssl/certs/java/cacerts
is filled with certificates afterwards:
root@768cffbd84c4:/tmp# dpkg --list | grep java
root@768cffbd84c4:/tmp# apt install -y ./adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'adoptopenjdk-11-hotspot' instead of './adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb'
The following additional packages will be installed:
ca-certificates-java java-common libasound2 libasound2-data libbsd0 libnspr4 libnss3 libsqlite3-0 libx11-6
libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxi6 libxrender1 libxtst6 multiarch-support x11-common
Suggested packages:
default-jre libasound2-plugins alsa-utils
The following NEW packages will be installed:
adoptopenjdk-11-hotspot ca-certificates-java java-common libasound2 libasound2-data libbsd0 libnspr4 libnss3
libsqlite3-0 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxi6 libxrender1 libxtst6 multiarch-support
x11-common
0 upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
[cut]
update-alternatives: using /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Setting up ca-certificates-java (20180516ubuntu1~18.04.1) ...
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory
Adding debian:QuoVadis_Root_CA_3_G3.pem
Adding debian:Staat_der_Nederlanden_Root_CA_-_G2.pem
[ cut]
root@768cffbd84c4:/tmp# dpkg --list | grep java
ii ca-certificates-java 20180516ubuntu1~18.04.1 all Common CA certificates (JKS keystore)
ii java-common 0.68ubuntu1~18.04.1 all Base package for Java runtimes
root@768cffbd84c4:/tmp# keytool -list -keystore /etc/ssl/certs/java/cacerts
Enter keystore password:
***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 133 entries
debian:affirmtrust_premium_ecc.pem, May 6, 2019, trustedCertEntry,
Certificate fingerprint (SHA-256): BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23
[cut]
Just for completeness:
root@768cffbd84c4:/tmp# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
Hello @aahlenst,
root@768cffbd84c4:/tmp# dpkg --list | grep java
ii ca-certificates-java 20180516ubuntu1~18.04.1 all Common CA certificates (JKS keystore)
ii java-common 0.68ubuntu1~18.04.1 all Base package for Java runtimes
Was adoptopenjdk installed successfully as well?
$ docker run --rm -it -v ~/Downloads/adoptopenjdk-8-hotspot_1.8.0\ 212-1_amd64.deb:/tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb debian:stretch-slim
root@dd6bde5b224d:/# apt-get -qq update
root@dd6bde5b224d:/# apt-get install /tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'adoptopenjdk-8-hotspot' instead of '/tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb'
The following additional packages will be installed:
ca-certificates ca-certificates-java java-common libasound2 libasound2-data libbsd0 libnspr4 libnss3 libsqlite3-0 libssl1.1 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxi6 libxrender1 libxtst6 openssl x11-common
Suggested packages:
default-jre libasound2-plugins alsa-utils
The following NEW packages will be installed:
adoptopenjdk-8-hotspot ca-certificates ca-certificates-java java-common libasound2 libasound2-data libbsd0 libnspr4 libnss3 libsqlite3-0 libssl1.1 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxi6 libxrender1 libxtst6 openssl x11-common
0 upgraded, 22 newly installed, 0 to remove and 4 not upgraded.
Need to get 6575 kB/111 MB of archives.
After this operation, 225 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
.... stripped downloads ...
Fetched 6575 kB in 1s (3363 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libxau6:amd64.
(Reading database ... 6316 files and directories currently installed.)
... stripped unpacking ...
Updating certificates in /etc/ssl/certs...
151 added, 0 removed; done.
Setting up libx11-data (2:1.6.4-3+deb9u1) ...
Setting up libxau6:amd64 (1:1.0.8-1) ...
Setting up libnss3:amd64 (2:3.26.2-1.1+deb9u1) ...
Setting up libxcb1:amd64 (1.12-1) ...
Setting up libx11-6:amd64 (2:1.6.4-3+deb9u1) ...
Setting up libxrender1:amd64 (1:0.9.10-1) ...
Setting up libxext6:amd64 (2:1.3.3-1+b2) ...
Setting up libxi6:amd64 (2:1.7.9-1) ...
Setting up libxtst6:amd64 (2:1.2.3-1) ...
Setting up ca-certificates-java (20170929~deb9u3) ...
/var/lib/dpkg/info/ca-certificates-java.postinst: line 56: java: command not found
dpkg: error processing package ca-certificates-java (--configure):
subprocess installed post-installation script returned error exit status 127
dpkg: dependency problems prevent configuration of adoptopenjdk-8-hotspot:
adoptopenjdk-8-hotspot depends on ca-certificates-java; however:
Package ca-certificates-java is not configured yet.
dpkg: error processing package adoptopenjdk-8-hotspot (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for ca-certificates (20161130+nmu1+deb9u1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
/etc/ca-certificates/update.d/jks-keystore: 90: /etc/ca-certificates/update.d/jks-keystore: java: not found
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Errors were encountered while processing:
ca-certificates-java
adoptopenjdk-8-hotspot
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@dd6bde5b224d:/#
The same thing happens when using debian:stretch
instead of debian:stretch-slim
.
And just for completeness the same happens on buster-slim
as well.
docker run --rm -it -v ~/Downloads/adoptopenjdk-8-hotspot_1.8.0\ 212-1_amd64.deb:/tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb debian:buster-slim /bin/bash -c 'apt-get -qq update ; export DEBIAN_FRONTEND=noninteractive; apt-get install -y --no-install-recommends /tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb'
Setting up adoptopenjdk-8-hotspot (1.8.0+212-1) ...
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/appletviewer to provide /usr/bin/appletviewer (appletviewer) in auto mode
update-alternatives: error: error creating symbolic link '/usr/share/man/man1/appletviewer.1.dpkg-tmp': No such file or directory
dpkg: error processing package adoptopenjdk-8-hotspot (--configure):
installed adoptopenjdk-8-hotspot package post-installation script subprocess returned error exit status 2
dpkg: dependency problems prevent configuration of ca-certificates-java:
ca-certificates-java depends on default-jre-headless | java8-runtime-headless; however:
Package default-jre-headless is not installed.
Package java8-runtime-headless is not installed.
Package adoptopenjdk-8-hotspot which provides java8-runtime-headless is not configured yet.
dpkg: error processing package ca-certificates-java (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.28-8) ...
Processing triggers for ca-certificates (20190110) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Errors were encountered while processing:
adoptopenjdk-8-hotspot
ca-certificates-java
E: Sub-process /usr/bin/dpkg returned an error code (1)
A possible "workaround" is to move ca-certificates-java
to be recommended instead of being depended upon. In the end you do not require certifacates they are only a good idea in General :-).
Then you may firstly install adoptopenjdk
and afterwards ca-certificates-java
I just executed the following in docker run --rm -it -v ~/Downloads/adoptopenjdk-8-hotspot_1.8.0\ 212-1_amd64.deb:/tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb ubuntu:bionic
and it did succeed indeed:
root@180bef3af5a2:/# apt-get -qq update
root@180bef3af5a2:/# export DEBIAN_FRONTEND=noninteractive
root@180bef3af5a2:/# apt-get install -y --no-install-recommends /tmp/adoptopenjdk-8-hotspot_1.8.0-212-1_amd64.deb
...
Setting up libxi6:amd64 (2:1.7.9-1) ...
Setting up adoptopenjdk-8-hotspot (1.8.0+212-1) ...
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/appletviewer to provide /usr/bin/appletviewer (appletviewer) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/extcheck to provide /usr/bin/extcheck (extcheck) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/idlj to provide /usr/bin/idlj (idlj) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jar to provide /usr/bin/jar (jar) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jarsigner to provide /usr/bin/jarsigner (jarsigner) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java to provide /usr/bin/java (java) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javac to provide /usr/bin/javac (javac) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javadoc to provide /usr/bin/javadoc (javadoc) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javah to provide /usr/bin/javah (javah) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javap to provide /usr/bin/javap (javap) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jcmd to provide /usr/bin/jcmd (jcmd) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jconsole to provide /usr/bin/jconsole (jconsole) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jdb to provide /usr/bin/jdb (jdb) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jdeps to provide /usr/bin/jdeps (jdeps) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jhat to provide /usr/bin/jhat (jhat) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jinfo to provide /usr/bin/jinfo (jinfo) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jjs to provide /usr/bin/jjs (jjs) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jmap to provide /usr/bin/jmap (jmap) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jps to provide /usr/bin/jps (jps) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jrunscript to provide /usr/bin/jrunscript (jrunscript) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jsadebugd to provide /usr/bin/jsadebugd (jsadebugd) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jstack to provide /usr/bin/jstack (jstack) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jstat to provide /usr/bin/jstat (jstat) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/jstatd to provide /usr/bin/jstatd (jstatd) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/native2ascii to provide /usr/bin/native2ascii (native2ascii) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/orbd to provide /usr/bin/orbd (orbd) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/pack200 to provide /usr/bin/pack200 (pack200) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/policytool to provide /usr/bin/policytool (policytool) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/rmic to provide /usr/bin/rmic (rmic) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/schemagen to provide /usr/bin/schemagen (schemagen) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/serialver to provide /usr/bin/serialver (serialver) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/servertool to provide /usr/bin/servertool (servertool) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/tnameserv to provide /usr/bin/tnameserv (tnameserv) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/wsgen to provide /usr/bin/wsgen (wsgen) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/wsimport to provide /usr/bin/wsimport (wsimport) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/xjc to provide /usr/bin/xjc (xjc) in auto mode
update-alternatives: using /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Setting up ca-certificates-java (20180516ubuntu1~18.04.1) ...
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory
Adding debian:Certigna.pem
Adding debian:thawte_Primary_Root_CA.pem
Adding debian:GlobalSign_Root_CA.pem
Adding debian:thawte_Primary_Root_CA_-_G3.pem
Adding debian:OpenTrust_Root_CA_G3.pem
...
As can be seen alternatives are set before running /etc/ca-certificates/update.d/jks-keystore
.
@mfriedenhagen Thanks for the additional information.
To summarize:
The upstream packages of Ubuntu have a hard dependency on ca-certificates-java
. The Debian packages do as well. Therefore I don't think it makes sense to put it on recommended
.
I thought some more about it.
Considering the Debian documentation about package relationships and ca-certificates-java has circular Depends on openjdk-8-jre-headless I lean towards avoiding the problem altogether by dropping the dependency on ca-certificates-java
.
Possible ways forward:
ca-certificates-java
for the AdoptOpenJDK packages.I'd prefer 2. Are there any objections?
I actually have an objection myself. It's usually a pain when applications maintain their own list of trusted CAs. In case a trusted certificate should be removed, it's easier if it can be done centrally using the facilities of the operating system.
Dropping completely would be fine for me. I guess people are able to add another package name during installations, this is way better than having a broken installation. My guess: Even when using recommended or suggested would trigger above bug on Debian and as a installing recommended packages is the default this would break for most people and you would have to explain how to circumvent this.
By making the installation of ca-certificates-Java a separate step, everyone has the freedom to choose whether they like the JDK provided or those of the OS.
Another observation:
/usr/local/share/ca-certificates/
and ran update-ca-certificates
.curl
was able to connect successfully to one of our internal systems because /etc/ssl/certs/ca-certificates.crt
was adapted./etc/ssl/certs/java/cacerts
was adapted as well.java -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
. Otherwise java will default to /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre/lib/security/cacerts
.It's correct that /etc/ssl/certs/java/cacerts
currently isn't picked up. I have a private version where lib/security/cacerts
is replaced with a symlink to /etc/ssl/certs/java/cacerts
. But that's pointless now if I'm going to drop ca-certificates-java
. The whole symlinking is also the reason why ca-certificates-java
is a hard dependency. If someone would not install it, they ended up without any trusted CA certificates at all. And modifying the contents of already installed packages is a no-go, too.
I just checked in an empty buster container. We need to "recommend" ca-certificates-java instead of "depending". By doing this java is installed first and when java installation is finished then ca-certificates-java is installed.
When cacerts is symlinked to /etc/ssl/certs/cacerts then the trustStore variable is not needed.
I think "recommend" package is not always installed .. it depend of tools apt/apt-get/aptitude and from config .. Isn't it a problem if ca-certificates-java isn't install at all ?
Well, so what happens then is that someone who explicitly said he does not need or want ca-certificates-java has no certificates, you could call this a feature as well. Then he or she has to take extra steps.
Recommends are installed by default (since Lucid)
but for many years ago "recommands" were traited as "suggest" ( and not installed by default ) and not often needed so since Lucid many admin disable recommands by default for many reason ( keep install minimal, cache, network, maybe security ) ( Only install the absolutely necessary is a admin mantra )
Yes I'm a old school admin. Maybe I'm must change my mind :)
@douph1,
--no-install-recommends
as well a lot.ca-certificates-java
additionally afterwards.I a really confused how the official debian openjdk packages handle this circular dependency. I think someone mentionend it before. The jre-headless package, which is required by all other java packages, has a dependency to itself in the same version.
Maybe we need some kind of updater like our internal one, that updates the certificates in the adoptopenjdk path. Or makes a diversion of the ca-certs file and symlinks it to the global one.
The recommends did not work well. Maybe because that strange self dependency is missing: https://github.com/nudgegoonies/openjdk-installer/tree/debian-cacerts-with-ca-certificates
Why can't we do it like Debian and just add the self-dependency? Probably this is a trick to enforce running any post-configure scripts of the package itself before starting to install it's required dependencies.
@aahlenst can this be closed now?
Well, the packages can be installed now. But I still plan to ship a proper fix that integrates better with the OS. But I haven't decided yet what that proper fix is going to be. It should fit RHEL/CentOS too.
So either we keep this one open (contains lots of valuable information) or close this one and open another.
For all those waiting: It might take some time. We're working hard on getting the stuff we have out of the door.
I was working on it 2 week ago and it worked only for stretch with the self dependency. But jessie seems to have a fundamental problem with circular and/or self dependencies leaving me with this:
E: Internal error: MaxLoopCount reached in SmartUnPack (2) for adoptopenjdk-8-hotspot:amd64, aborting
E: Internal error, packages left unconfigured. ca-certificates-java:amd64
https://github.com/nudgegoonies/openjdk-installer/commit/9db7a4dfadd7e111a837425f741ece90d31a68ad
I havn't tested buster yet. I have an internal gitlab-ci pipeline so testing for buster should be easy when i have time again.
And there is another thing that depending on jre/jdk/java version the path tho the file is different.
I am still unsure if this needs to be patched in debian too: https://salsa.debian.org/java-team/ca-certificates-java/blob/master/debian/jks-keystore.hook.in
I added an MR but this needs further testing first: https://salsa.debian.org/java-team/ca-certificates-java/merge_requests/3
I tried again and with my changes on ca-certificates-java the circular dependency between jdk and ca-certificates works in debian buster but not in stretch. No i remamber that someone in the past reported it worked in ubuntu while it did non work in debian. Testing this needs a big distro-test-matrix :(
With my latest changes in ca-certificate-java it worked also for stretch. My i have to build the test-matrix for all debians and ubuntus.
@aahlenst One question. I've just found the official Jenkins instance. But i can't find the build-pipeline or build-job that builds the deb/rpm packages and uploads it to Artifactory. We have own Jenkins/Artifactory instances here and i want could test my changes together with my changes to ca-certificates-java.
@nudgegoonies https://ci.adoptopenjdk.net/job/build-scripts/job/release/. The relevant jobs are artifactory_release_publisher
and create_installer_linux
. But I don't think they are public. And they have some issues, too. I'm currently prepping revised jobs that are going to be part of the public repository. But there's nothing magic about them: They just call the various Gradle tasks.
As a heads-up: I still plan to replace ca-certificates-java with a dedicated tool that works both on Debian-based and Red-Hat-based distributions. If you're heavily invested in ca-certificates-java
, please share your requirements.
@aahlenst You are right. The jenkins jobs are not public. I made myself a little script to download the tar.gzs and call the grade tasks at least for the lts 8 and 11 versions to build my branch.
Can i ask how do you want to update the cacerts file? @mfriedenhagen tried generating a JKS keystore with openssl but the JKS keystore needs a kind of tag for every keystore entry that openssl does not provide.
If it cannot be written in java i only found a python program that can handle JKS files.
I tried using an PKCS12 keystore with AdoptOpenJDK but i failed too. I still don't know if the format itself is the problem of my configuration of the security file.
Or do you explicit want to use the AdoptOpenJDK own keytool after unpacking of the package and a postinst script that generates the cacerts keystore from the debian/rpm certificates by using the unpacked AdoptOpenJDK? This sounds like the easiest solution. But it would be veriy similar ca-certificates-java. The problem with the circular dependency is solved by that.
Another thing to keep in mind is the location and declaration of the cacerts files as a configuration file. Actually we have the problem that during package updates the cacerts file from AdoptOpenJDK is overwritten because it is not declared as configuration file. We have to call our internal tool again to add our inhouse certificates after every update.
Just as followup, I did try to create a PKCS12 keystore usable by Java using only openssl but did not succeed, because Java only trusts certs in a PKCS12 keystore with "bag attributes"
After I converted the included JKS truststore to PKCS12 (keytool -export -srckeystore /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/security/cacerts -destkeystore cacerts.p12-fromjks -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit
) when gathering info from this one I get:
$ openssl pkcs12 -info -in cacerts.p12-fromjks -passin pass:changeit
[...]
Certificate bag
Bag Attributes
friendlyName: digicertglobalrootca [jdk]
2.16.840.1.113894.746875.1.1: <Unsupported tag 6>
subject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----
$
When trying to convert a "standard" pem cacerts file with openssl pkcs12 -export -cacerts -nokeys -passout pass:changeit < /usr/local/etc/openssl/cert.pem > cacacerts.p12-from-cert.pem
I do not see any bag attributes when running above openssl pkcs12 -info -in cacerts.p12-from-cert.pem -passin pass:changeit
. And keytool
does find no entries (Einträge):
$ keytool -list -keystore cacerts.p12-from-cert.pem -storepass changeit
Keystore-Typ: PKCS12
Keystore-Provider: SUN
Keystore enthält 0 Einträge
while with the one converted from JKS I get 92 entries (Einträge):
$ keytool -list -keystore cacerts.p12-fromjks -storepass changeit | head
Keystore-Typ: PKCS12
Keystore-Provider: SUN
Keystore enthält 92 Einträge
verisignclass2g2ca [jdk], 01.08.2019, trustedCertEntry,
Zertifikat-Fingerprint (SHA1): B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D
digicertassuredidg3 [jdk], 01.08.2019, trustedCertEntry,
Zertifikat-Fingerprint (SHA1): F5:17:A2:4F:9A:48:C6:C9:F8:A2:00:26:9F:DC:0F:48:2C:AB:30:89
verisignuniversalrootca [jdk], 01.08.2019, trustedCertEntry,
[...]
But: even with the PKCS12 truststore created from the JKS default (with the bag attributes) I did not get java to trust it without explicitly passing javax.net.ssl.trustStorePassword=changeit
:-(
Hi Jakub, i already created a MR to include the adopt jdk/jre paths in ca-certificates-java and tried this modified ca-certificates-java package with no luck: https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/3/diffs?view=parallel See my comments upwards in this thread. Kind regards, Andreas
Hi nungegoonies,
thanks for your reply. I have (too late) realized that the code snippet I sent was exactly the one that is in the first post and so I did not bring anything new, so I deleted my comment, for which I apologize.
I haven't noticed the PR, thank you for the link, I will read through it.
Best regards,
Jakub
Good news: This is fixed. 😅 Bad news: The fix is in a holding pattern until Adoptium arrives and I've redone the JDK/JRE packages. I don't want to wrestle with the old infrastructure anymore.
Details: For Debian, there will be a separate package (temporary name: adoptium-ca-certificates
). This replaces ca-certificates-java
from Debian/Ubuntu. It comes without the circular dependency and only depends on ca-certificates
and p11-kit
. A JRE/JDK isn't necessary for its operation. It integrates with the system's certificate store and its cacerts is automatically updated with update-ca-certificates
as the Debian JDK. /etc/ssl/certs/adoptium/cacerts
is going to serve as shared keystore for all Adoptium runtimes and will be symlinked.
I did not port the option to use a different keystore password than the default (changeit
) or the option to sideload certificates that aren't included in the local certificate store /usr/local/share/ca-certificates/
. If anybody needs that, please speak up. It's still possible to disable the automatic update via /etc/default/adoptium-ca-certificates
.
Red Hat and SUSE flavours won't need it because their ca-certificates
has a cacerts included.
If anyone wants to follow the development, it's currently on https://github.com/aahlenst/adoptium-ca-certificates and awaiting it's permanent home. And this time, we even have a full test suite that ensures everything's working across the board 🤞
Because of the dependency of adoptopenjdk-* to ca-certificates-java in debian they are installed at the same time. For some reason both cannot be installed at the same time because ca-certificates-java needs a ready installed java to execute java but ca-certificates-java seems to be installed first so there is no java executable yet.
We have to look how openjdk-8-jre-headless does the magic in the debian package. It seems that the problem is this:
I think we could and should patch upstream to include also adoptopenjdk.
But for now i think we have to remove the dependency to ca-certificates-java.