This is a clone of Bug 160387 for Java: my company maintains internal CAs which is distributed with the cacerts (Oracle-provided + ours) with the company-wide JRE distribution. I need those cacers on our BSD servers too, copied it and have: Checking for packages with mismatched checksums: openjdk-7.161.01,1: /usr/local/openjdk7/jre/lib/security/cacerts openjdk8-8.172.11: /usr/local/openjdk8/jre/lib/security/cacerts Please some means for a custom/mergeable cacerts.
The problem is really a general problem with how this is designed in Java. I am inclined to refuse this suggestion since it would now be compatible with other OS:es javas. The preferred way to do this in Java is `java -Djavax.net.ssl.trustStore=/home/girgen/mycacerts` or similar. I agree that this sucks, but fixing it only for FreeBSD is not the best option, IMO. Feel free to disagree. :) Palle
(In reply to Palle Girgensohn from comment #1) Misspelt: ... would NOT be compatible... sorry for the confusion.
> The problem is really a general problem with how this is designed in Java. I am inclined to refuse this suggestion since it would now be compatible with other OS:es javas. I do not fully agree because other OSes do derive cacerts from Mozilla's public list. OpenJDK does not yet include a cacerts. BTW, RHEL provides an overly complex option to solve bug 229329. > -Djavax.net.ssl.trustStore=/home/girgen/mycacerts Isn't really an option because I would miss all public CAs. It'd be cat-and-mice-game to chase both which I don't want to do. Moreover, hooking this into each and very possible application is a pain. I'd like to hear Greg Lewis stance on this and since 229329 has not been rejected yet, I'd be fair to keep this one open. I guess I am not the only idiot having this problem. At best 229329 would be resolved and the ports system would derive the cacarts from the ca_root_nss: https://packages.ubuntu.com/bionic/ca-certificates-java
(In reply to Michael Osipov from comment #3) I was not aware that the cacert list in java didn't come from openjdk. I see now that is locally maintained in $FILESDIR/cacerts. This is probably since it is copied into $PREFIX/openjdk8/jre/lib/security/ and we want the openjdk8 package to be consistently build for a certain version of the port. Deriving the OpenJDK CA roots file from security/ca_root_nss is probably equal yo getting it from https://packages.ubuntu.com/bionic/ca-certificates-java and this is problaby what happens except it is done manually when the port is updated. It would not help you with your problem, since it would still give you the same problems with "mismatched checksums" warnings if you added your own CA:s to it. Now, with a local copy of the list, you could manage the suggested "local" list "/home/girgen/cacerts" by copying the "big" cacert list from ubuntu *or* ca_root_nss *or* OpenJDK:s built-in cacerts, and adding your own CA:s at the end, just as you are doing now except using a different file. By using your own file you would not get pkg nagging about checksums. Still this is a hassle in that every java application needs this `-Djavax.net.ssl.trustStore=/home/girgen/mycacerts` flag, but I still think that is a general Java problem that should not be handled for one platform. You can of course choose to ignore the checksum warnings, but there is no easy way around the fact that editing a file installed by the package system will render a checksum error if you manually change that. Also, every time you update java, you need to re-add your additions. Still, I'm open to suggestions. Greg's input would of course also be valuable. You are definitely not the only one with this problem!
(In reply to Palle Girgensohn from comment #4) Switching to security/ca_root_nss would solve my problem if and only if bug 160387 would be resolved. It would make cert usage on the system consistent across implementations within a company. What I did for the moment is > $ svn diff /usr/ports/security/ca_root_nss/ > Index: /usr/ports/security/ca_root_nss/Makefile > =================================================================== > --- /usr/ports/security/ca_root_nss/Makefile (Revision 473303) > +++ /usr/ports/security/ca_root_nss/Makefile (Arbeitskopie) > @@ -54,6 +54,7 @@ > ${PERL} ${WRKDIR}/${BUNDLE_PROCESSOR} \ > < ${WRKDIR}/certdata.txt > \ > ${WRKDIR}/ca-root-nss.crt > + @${CAT} ${FILESDIR}/siemens_ca_certificates.pem >> ${WRKDIR}/ca-root-nss.crt > > do-install: > ${MKDIR} ${STAGEDIR}${PREFIX}/${CERTDIR} Ignoring cert errors is absolutely not an option.
(In reply to Palle Girgensohn from comment #1) I disagree. CentOS/RHEL have solved this problem which makes them a great platform for Enterprise Java apps. It's our responsibility to solve this ourselves. Please see this review: https://reviews.freebsd.org/D16352
(In reply to Mark Felder from comment #6) Is there anything I can do to make this happen? I have proposed a few changes to the differential as well as a very elaborated usecase from work.
For those who care: If all goes well, Java 14 will move cacerts keystore to a PEM file just like OpenSSL uses: http://cr.openjdk.java.net/~weijun/8162628/webrev.00/ I have initiated this change. The original idea was to move to a passwordless PKCS12 keystore which I have vetoed.
(In reply to Michael Osipov from comment #8) This has been stalled due to performance issues with Base64.
Created attachment 239958 [details] Git-formatted patch Here is a patch against main which basically adds an option to use a custom cacerts from LOCALBASE. This is the easiest approach to solve this problem now until openssl can directly creata Java-compatible PKCS#12 truststores: https://github.com/openssl/openssl/issues/6684 Works in production and poudriere. Can provide a patch for 11 and 17+ as well, of course. Simple port used at work: ========================= PORTNAME= nss-siemens-cacerts-java PORTVERSION= 20221107 CATEGORIES= security DISTFILES= MAINTAINER= michael.osipov@siemens.com COMMENT= Collection of CA certificates trusted by NSS and Siemens for Java NO_ARCH= yes NO_BUILD= yes NO_TEST= yes WRKSRC= ${FILESDIR} SSLDIR= ${PREFIX}/etc/ssl PLIST_SUB= SSLDIR=${SSLDIR} do-install: @${MKDIR} ${STAGEDIR}${SSLDIR} @${INSTALL_DATA} ${WRKSRC}/cacerts.jks ${STAGEDIR}${SSLDIR}/cacerts .include <bsd.port.mk> ================== cacerts.jks is generated with a custom Java application.
Created attachment 239959 [details] Git-formatted patch
Port maintainer or someone else, can you have a look? I can easily rebase and create patches for other LTS versions as well.
Greg, any chance to look at this since you are back now?
Raised https://reviews.freebsd.org/D42720
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d901bf5df9d22af271582c28d9dc279a6794f3d0 commit d901bf5df9d22af271582c28d9dc279a6794f3d0 Author: Michael Osipov <michaelo@FreeBSD.org> AuthorDate: 2023-11-22 13:08:23 +0000 Commit: Michael Osipov <michaelo@FreeBSD.org> CommitDate: 2024-02-09 19:52:07 +0000 java/openjdk*: Allow users to specify an alternative cacerts file Similar to certificate management with certctl(8) users can use custom enterprise CAs. These need to be assembled into a custom cacerts file. Therefore, an admin can install a custom truststore to an arbitrary location and have the OpenJDK port symlink to it by adding OPENJDK_SYMLINK_CACERTS to make.conf. E.g., OPENJDK_SYMLINK_CACERTS=/usr/local/etc/ssl/cacerts. PR: 229329 Approved by: jrm (mentor), otis (mentor), glewis Differential Revision: https://reviews.freebsd.org/D42720 java/openjdk11/Makefile | 7 +++++++ java/openjdk17/Makefile | 7 +++++++ java/openjdk21/Makefile | 7 +++++++ java/openjdk8/Makefile | 5 +++++ 4 files changed, 26 insertions(+)
After almost six years this change has landed in ports. You need to build a custom port with the make variable set. A better approach can be implemented when OpenSSL 3.2 is in base which can create Java-aware truststores from the system truststores.