Bug 229329 - java/openjdk8: allow user to trust extra local certificates
Summary: java/openjdk8: allow user to trust extra local certificates
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-java (Nobody)
Depends on:
Reported: 2018-06-25 08:50 UTC by Michael Osipov
Modified: 2021-05-05 09:40 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (java)


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2018-06-25 08:50:19 UTC
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.
Comment 1 Palle Girgensohn freebsd_committer 2018-06-25 09:29:50 UTC
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. :)

Comment 2 Palle Girgensohn freebsd_committer 2018-06-25 09:32:09 UTC
(In reply to Palle Girgensohn from comment #1)
Misspelt: ... would NOT be compatible... sorry for the confusion.
Comment 3 Michael Osipov 2018-06-25 12:31:25 UTC
> 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
Comment 4 Palle Girgensohn freebsd_committer 2018-06-25 15:31:34 UTC
(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!
Comment 5 Michael Osipov 2018-06-26 09:22:41 UTC
(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:

Ignoring cert errors is absolutely not an option.
Comment 6 Mark Felder freebsd_committer 2018-07-20 17:00:23 UTC
(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:

Comment 7 Michael Osipov 2019-02-19 21:28:10 UTC
(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.
Comment 8 Michael Osipov 2019-08-13 19:44:07 UTC
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.
Comment 9 Michael Osipov 2021-05-05 09:40:47 UTC
(In reply to Michael Osipov from comment #8)

This has been stalled due to performance issues with Base64.