1

We are using Java 8 to run an application on an AWS instance. The application was configured to look in the CAcerts for a Trusted cert. When the application was written it only used the path/name to CAcerts. It was not configured with TrustStore type or password.

Everything worked fine until a few months ago when it stopped working. We discovered at that point that the type and password HAD to be specified to read the CAcerts. I understood this was always the default position back it appears not.

Back in 2010 you didn't need a password to list the content of CAcerts. StackOverflow link here.

Then in 2018 it appears you do have to provide a password to list the contents. StackOverflow link here.

Somewhere in between those two dates there was a change. The relase notes for Java 8 here do tell me anything so can anyone tell me when this change occurred?

Thanks,

Eddie

enter image description here

Eddieturbo
  • 25
  • 4
  • Are you sure the file was _created_ with j8? j9 up by default creates PKCS12 which requires a password to read certs while JKS (the default below j9) does not -- if the program is coded that way, which keytool is but your app we don't know. However, even if the file is PKCS12, updates of 8 from 8u60 up should be able to read it using the default _type_ unless someone has changed the java.security file (or the keystore.type.compat security property). Check the first 2 bytes of the file: are they `feed` (JKS) or `3082` (PKCS12)? When/how was the file modified? – dave_thompson_085 Oct 22 '20 at 11:18
  • @dave_thompson_085 Thanks for that. So I looked at a basic t2.micro AWS AMI and was able to recreate the issue. I ran a 'yum install java' to update to the latest available. The cacert truststore is provided as part of the build and we never change. openjdk version "1.8.0_265", OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode) # keytool -list -keystore /etc/pki/java/cacerts > Enter keystore password: # changeit > Keystore type: **jks** > Keystore provider: SUN. – Eddieturbo Oct 22 '20 at 13:06
  • _All_ EC2 instances run from one of about 60,000 AMIs so that doesn't help much. As I won't pay for this, the quick-launch wizard only has 40 on free tier and only a few of those use `yum`, so I tried the first -- Amazon Linux 2 (HVM), name: amzn2-ami-hvm-2.0.20200917.0-x86_64-gp2 id: ami-03657b56516ab7912 . `sudo yum install java` on that AMI gets _11-corretto_, and `... java-1.8.0` gets `java-1.8.0-openjdk .x86_641.8.0.265.b01-1.amzn2.0.1` which uses `/etc/pki/ca-trust/extracted/java/cacerts` /from a different package ca-certificates.noarch 2019.2.32-76.amzn2.0.3` which is a JKS file ... – dave_thompson_085 Oct 27 '20 at 07:18
  • ... and the `keytool` from that java can indeed list 137 certs from that cacerts file with no password just fine. This does not support your claim. Neither does 8u265 keytool showing the type as JKS; as I said, 8u60 up has a compatibility feature where the program (keytool) uses the API for JKS but it nonetheless can read either JKS _or_ PKCS12 -- the _latter_ only with the password. Without details on the file you are actually using I continue not to believe there is any JKS _file_ you can't read without a password. – dave_thompson_085 Oct 27 '20 at 07:22
  • Hi @dave_thompson_085, thanks for sticking with this. I must be doing something really basic here. See the image here: https://i.stack.imgur.com/ZJL0G.png Bottom line is that I get prompted and once I enter the password it tells me its a JKS format !!! What am I doing wrong here? – Eddieturbo Nov 03 '20 at 14:16
  • (1) You are always _prompted_. Did you try not _entering_ the password (just hit return)? IF it's JKS that will work. (2) But as I said, for 8u60 up keytool can _say_ the type is JKS even though it is actually PKCS12. IF without the password it says 0 entries, LOOK AT THE FILE. – dave_thompson_085 Nov 04 '20 at 09:25

0 Answers0