Re: [Q] 9.1 amd64 openJDK11 error on certificates

[ts1000 <ts1000%rad2know.net@localhost>]

I have logged an issue ( 
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55758 ) on 
this.
However, would appreciate if somebody could help with guidance on this.

I had found a cacerts file in the openjdk directory and seems to contain 
entries (see below)
but it is not clear what I need to do so that gradle and anything else 
thats trying to use https in openJDK11 would work

---

nbsd1# pwd
/usr/pkg/java/openjdk11/lib/security
nbsd1# keytool -list -keystore cacerts  -storepass changeit | more
Warning: use -cacerts option to access cacerts keystore
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 146 entries

mozilla-rootcert-0, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
EB:D4:10:40:E4:BB:3E:C7:42:C9:E3:81:D3:1E:F2:A4:1A:48:B6:68:5C:96:E7:CE:F3:C1:DF:6C:D4:33:1C:99
mozilla-rootcert-1, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
mozilla-rootcert-10, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
A0:23:4F:3B:C8:52:7C:A5:62:8E:EC:81:AD:5D:69:89:5D:A5:68:0D:C9:1D:1C:B8:47:7F:33:F8:78:B9:5B:0B
mozilla-rootcert-100, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
17:9F:BC:14:8A:3D:D0:0F:D2:4E:A1:34:58:CC:43:BF:A7:F5:9C:81:82:D7:83:A5:13:F6:EB:EC:10:0C:89:24
mozilla-rootcert-101, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
3C:4F:B0:B9:5A:B8:B3:00:32:F4:32:B8:6F:53:5F:E1:72:C1:85:D0:FD:39:86:58:37:CF:36:18:7F:A6:F4:28
mozilla-rootcert-102, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
4D:24:91:41:4C:FE:95:67:46:EC:4C:EF:A6:CF:6F:72:E2:8A:13:29:43:2F:9D:8A:90:7A:C4:CB:5D:AD:C1:5A
mozilla-rootcert-103, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
5D:56:49:9B:E4:D2:E0:8B:CF:CA:D0:8A:3E:38:72:3D:50:50:3B:DE:70:69:48:E4:2F:55:60:30:19:E5:28:AE
mozilla-rootcert-104, Oct 30, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 
30:D0:89:5A:9A:44:8A:26:20:91:63:55:22:D1:F5:20:10:B5:86:7A:CA:E1:2C:78:EF:95:8F:D4:F4:38:9F:2F
--More--(byte 1565)




On 2020-10-25 18:26, ts1000 wrote:
> Thank you for the followups. I do not think I am clear on what I need
> to do to fix it.
>
> Is there a specific package that I could install with pkgin or from
> pkgsrc that could fix this?
>
> I have made my dev environment work with OpenJDK11 on OpenBSD, FreeBSD
> as well as others. But in those, there were no additional steps
> needed.
> So I am just not very familiar with this niche of setting up
> certificates for a jdk installation.
>
> Thank you in advance for any guidance.
>
> On 2020-10-25 09:43, Mike Pumford wrote:
> > On 25/10/2020 07:56, Michael van Elst wrote:
> > > ts1000%rad2know.net@localhost (ts1000) writes:
> > >
> > > > But that first step is not working on netBSD-9.1 amd64
> > > > I tried with pkgin, as well as building openjdk11 from source.
> > > > Error is the same.
> > >
> > > > I also installed, with pkgin,
> > > > ca-certificates-20200601
> > > > mozilla-rootcerts-1.0.20200529nb1
> > >
> > > The mozilla certificates aren't used by Java. You probably have to
> > > import them with keytool or similar.
> > That's true they are not. Java 8 builds its own cert store when it
> > builds. Looking at my Java 11 pkgsrc build from last week it appears
> > to import the mozilla root certs into its keystore as part of the
> > build process.
> >
> > However at the end of the build process the openjdk8 package installs
> > the certificate in the install phase but the openjdk11 package does
> > not!
> >
> > No I know that some NetBSD people are against auto cert install but
> > given the pain of doing it for java it should probably be at least a
> > package option and in the absence of an option it seems to me that
> > mimicing openjdk8 and installing the certs is a good idea.
> >
> > I'd be strongly against not installing the certs on openjdk8 as that
> > would mean I'd have to manually fix that up every time I did a package
> > update.
> >
> > Mike