| 2017-12-21 15:49:25 |
Antti S. Lankila |
bug |
|
|
added bug |
| 2018-01-24 21:55:44 |
Launchpad Janitor |
ca-certificates-java (Ubuntu): status |
New |
Confirmed |
|
| 2018-04-17 06:19:21 |
Nigel Kukard |
bug |
|
|
added subscriber Nigel Kukard |
| 2018-04-18 16:01:42 |
pkmo-linux |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894979 |
|
| 2018-04-22 23:38:27 |
mjw99 |
bug |
|
|
added subscriber mjw99 |
| 2018-04-28 16:53:45 |
Mikael Gueck |
bug |
|
|
added subscriber Mikael Gueck |
| 2018-05-02 18:11:43 |
Chris Hubbard |
bug |
|
|
added subscriber Chris Hubbard |
| 2018-05-09 09:52:47 |
Launchpad Janitor |
ca-certificates-java (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2018-05-11 12:44:32 |
Liam Stanley |
bug |
|
|
added subscriber Liam Stanley |
| 2018-05-15 14:12:45 |
Tiago Stürmer Daitx |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898678 |
|
| 2018-05-15 14:12:45 |
Tiago Stürmer Daitx |
bug task added |
|
ca-certificates-java (Debian) |
|
| 2018-05-15 14:43:16 |
Bug Watch Updater |
ca-certificates-java (Debian): status |
Unknown |
New |
|
| 2018-05-17 13:34:39 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-05-17 13:34:39 |
Julian Andres Klode |
bug task added |
|
ca-certificates-java (Ubuntu Bionic) |
|
| 2018-05-17 13:34:48 |
Julian Andres Klode |
ca-certificates-java (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2018-05-17 13:34:53 |
Julian Andres Klode |
ca-certificates-java (Ubuntu): importance |
Undecided |
High |
|
| 2018-05-17 13:35:19 |
Julian Andres Klode |
ca-certificates-java (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-05-17 16:03:32 |
Bug Watch Updater |
ca-certificates-java (Debian): status |
New |
Fix Released |
|
| 2018-05-18 05:15:13 |
Peter Hull |
bug |
|
|
added subscriber Peter Hull |
| 2018-05-18 23:48:52 |
Don-vip |
bug |
|
|
added subscriber Don-vip |
| 2018-05-25 15:31:56 |
Kai |
bug |
|
|
added subscriber Kai |
| 2018-06-05 06:59:51 |
chikei |
bug |
|
|
added subscriber chikei |
| 2018-06-19 16:58:57 |
Brian Murray |
ca-certificates-java (Ubuntu Bionic): milestone |
|
ubuntu-18.04.1 |
|
| 2018-06-20 15:25:05 |
Matthias Klose |
ca-certificates-java (Ubuntu Bionic): assignee |
|
Tiago Stürmer Daitx (tdaitx) |
|
| 2018-07-01 05:45:16 |
Sam Uong |
ca-certificates-java (Ubuntu Bionic): status |
Triaged |
Confirmed |
|
| 2018-07-17 08:41:20 |
Pavel |
bug |
|
|
added subscriber Pavel |
| 2018-07-17 16:19:52 |
Tiago Stürmer Daitx |
description |
I ran into a problem after doing approximately the following on an install of Ubuntu 17.10:
sudo apt-get install openjdk-9-jdk maven ca-certificates-java
Running "mvn package" on my own project threw this error without downloading anything:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
It seems that all TLS connections fail due to missing trust anchors in Java 9!
After some investigation, I discovered that the JDK's lib/security/cacerts is a symlink to /etc/ssl/certs/java/cacerts, which is provided by ca-certificates-java package. This file appeared to be a PKCS12 file with password "changeit" protecting it. I was able to list its contents using both keytool -list -cacerts and openssl pkcs12 -in cacerts with that password, confirming that the file actually did hold the certificates. Regardless, Java 9 was not able to use the contents of this file for whatever reason.
To workaround the issue, I downgraded to openjdk-8-jdk, did rm /etc/ssl/certs/java/cacerts, then did update-ca-certificates -f, then upgraded back to openjdk-9-jdk. The old Java 8 -generated JKS file with empty string as password was usable in the Java 9, permitting mvn and other things to make TLS connections again.
The problem can be reintroduced by having java 9 installed and doing rm /etc/ssl/certs/java/cacerts and then update-ca-certificates -f.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ca-certificates-java 20170930
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64
ApportVersion: 2.20.8-0ubuntu5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 21 17:36:05 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-12-21 (0 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=fi_FI.UTF-8
SHELL=/bin/bash
SourcePackage: ca-certificates-java
UpgradeStatus: Upgraded to bionic on 2017-12-21 (0 days ago)
modified.conffile..etc.default.cacerts: [inaccessible: [Errno 13] Lupa evätty: '/etc/default/cacerts'] |
[Impact]
Any user doing a new install can be affected as soon as they install any openjdk-11 package.
[Cause]
The ca-certificate-java version 20170930 (or earlier) used OpenJDK's default keystore to create /etc/ssl/certs/java/cacerts - if the file already existed its contents were just updated without changing the keystore type.
From openjdk-9 upwards the default keystore type changed from 'jks' to 'pkcs12' [1] by means of JEP 229 [2]. A JKS keystore can be read without supplying a password (or by supplying an empty one) while a PKCS12 keystore requires a password to be set.
Thus a /etc/ssl/certs/java/cacerts created in the pkcs12 format will fail to be loaded as, by default, the truststore password is empty - in order to avoid that the user must set -Djavax.net.ssl.trustStorePassword=<passwd> or define it in /etc/java-XX-openjdk/management/management.properties. A JKS keystore will work normally, as the certificates in it can be ready when the truststore password is empty.
Ubuntu does *not* set the javax.net.ssl.trustStorePassword by default
thus any user that got a cacerts generated in JKCS12 won't be able
to use any secure connections from java.
[Test Case]
Start on a new bionic install/chroot without openjdk
1. Install openjdk-11
$ sudo apt-get install openjdk-11-jdk
2. Test the keystore with an empty password (optional) and make sure it is a PKCS12
$ keytool -list -cacerts
Enter keystore password: <leave empty>
***************** 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: PKCS12
Keystore provider: SUN
Your keystore contains 0 entries
3. Test with the "changeit" password
$ keytool -list -cacerts
Enter keystore password: changeit
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 133 entries
<snipped various certs>
4. Create the java test file
$ cat <<EOF >HttpsTester.java
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
public class HttpsTester {
public static void main(String[] args) throws java.io.IOException {
HttpsURLConnection connection = (HttpsURLConnection) new URL("https://www.ubuntu.com").openConnection();
System.out.println("Response code: " + connection.getResponseCode());
System.out.println("It worked!");
}
}
EOF
5. Compile it
$ javac HttpsTester.java
6. Call it
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java HttpsTester
7. Call it again, this time set the store password
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Djavax.net.ssl.trustStorePassword=changeit HttpsTester
Response code: 200
It worked!
8. Install the newer ca-certificates-java 20180516, it should
migrate cacerts from PKCS12 to JKS. Check that by running step #2
again
$ keytool -list -cacerts
Enter keystore password: <leave empty>
***************** 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
<snipped various certs>
9. The old keystore should be saved in
/etc/ssl/certs/java/cacerts.dpkg-old, test it exists:
$ keytool -list -keystore /etc/ssl/certs/java/cacerts.dpkg-old
Enter keystore password: <leave empty>
***************** 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: PKCS12
Keystore provider: SUN
Your keystore contains 0 entries
[Regression Potential]
* If a user has manually set his own JKCS12 cacerts and didn't update
/etc/default/cacerts to set "cacerts_updates=no" (from the default
of "cacerts_updates=yes") then his custom cacerts will be converted and overwritten. Still, a copy from the previous cacert is kept at
/etc/ssl/certs/java/cacerts.dpkg-old.
[References]
[1] The default keystore is defined by the keystore.type in the
/etc/java-XX-openjdk/security/java.security file.
http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/annotate/46bd35a597eb/src/java.base/share/conf/security/java.security#l186
[2] JEP 229: Create PKCS12 Keystores by Default
http://openjdk.java.net/jeps/229
[Original bug description]
I ran into a problem after doing approximately the following on an install of Ubuntu 17.10:
sudo apt-get install openjdk-9-jdk maven ca-certificates-java
Running "mvn package" on my own project threw this error without downloading anything:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
It seems that all TLS connections fail due to missing trust anchors in Java 9!
After some investigation, I discovered that the JDK's lib/security/cacerts is a symlink to /etc/ssl/certs/java/cacerts, which is provided by ca-certificates-java package. This file appeared to be a PKCS12 file with password "changeit" protecting it. I was able to list its contents using both keytool -list -cacerts and openssl pkcs12 -in cacerts with that password, confirming that the file actually did hold the certificates. Regardless, Java 9 was not able to use the contents of this file for whatever reason.
To workaround the issue, I downgraded to openjdk-8-jdk, did rm /etc/ssl/certs/java/cacerts, then did update-ca-certificates -f, then upgraded back to openjdk-9-jdk. The old Java 8 -generated JKS file with empty string as password was usable in the Java 9, permitting mvn and other things to make TLS connections again.
The problem can be reintroduced by having java 9 installed and doing rm /etc/ssl/certs/java/cacerts and then update-ca-certificates -f.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ca-certificates-java 20170930
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64
ApportVersion: 2.20.8-0ubuntu5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 21 17:36:05 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-12-21 (0 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=fi_FI.UTF-8
SHELL=/bin/bash
SourcePackage: ca-certificates-java
UpgradeStatus: Upgraded to bionic on 2017-12-21 (0 days ago)
modified.conffile..etc.default.cacerts: [inaccessible: [Errno 13] Lupa evätty: '/etc/default/cacerts'] |
|
| 2018-07-17 17:06:29 |
Tiago Stürmer Daitx |
description |
[Impact]
Any user doing a new install can be affected as soon as they install any openjdk-11 package.
[Cause]
The ca-certificate-java version 20170930 (or earlier) used OpenJDK's default keystore to create /etc/ssl/certs/java/cacerts - if the file already existed its contents were just updated without changing the keystore type.
From openjdk-9 upwards the default keystore type changed from 'jks' to 'pkcs12' [1] by means of JEP 229 [2]. A JKS keystore can be read without supplying a password (or by supplying an empty one) while a PKCS12 keystore requires a password to be set.
Thus a /etc/ssl/certs/java/cacerts created in the pkcs12 format will fail to be loaded as, by default, the truststore password is empty - in order to avoid that the user must set -Djavax.net.ssl.trustStorePassword=<passwd> or define it in /etc/java-XX-openjdk/management/management.properties. A JKS keystore will work normally, as the certificates in it can be ready when the truststore password is empty.
Ubuntu does *not* set the javax.net.ssl.trustStorePassword by default
thus any user that got a cacerts generated in JKCS12 won't be able
to use any secure connections from java.
[Test Case]
Start on a new bionic install/chroot without openjdk
1. Install openjdk-11
$ sudo apt-get install openjdk-11-jdk
2. Test the keystore with an empty password (optional) and make sure it is a PKCS12
$ keytool -list -cacerts
Enter keystore password: <leave empty>
***************** 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: PKCS12
Keystore provider: SUN
Your keystore contains 0 entries
3. Test with the "changeit" password
$ keytool -list -cacerts
Enter keystore password: changeit
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 133 entries
<snipped various certs>
4. Create the java test file
$ cat <<EOF >HttpsTester.java
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
public class HttpsTester {
public static void main(String[] args) throws java.io.IOException {
HttpsURLConnection connection = (HttpsURLConnection) new URL("https://www.ubuntu.com").openConnection();
System.out.println("Response code: " + connection.getResponseCode());
System.out.println("It worked!");
}
}
EOF
5. Compile it
$ javac HttpsTester.java
6. Call it
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java HttpsTester
7. Call it again, this time set the store password
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Djavax.net.ssl.trustStorePassword=changeit HttpsTester
Response code: 200
It worked!
8. Install the newer ca-certificates-java 20180516, it should
migrate cacerts from PKCS12 to JKS. Check that by running step #2
again
$ keytool -list -cacerts
Enter keystore password: <leave empty>
***************** 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
<snipped various certs>
9. The old keystore should be saved in
/etc/ssl/certs/java/cacerts.dpkg-old, test it exists:
$ keytool -list -keystore /etc/ssl/certs/java/cacerts.dpkg-old
Enter keystore password: <leave empty>
***************** 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: PKCS12
Keystore provider: SUN
Your keystore contains 0 entries
[Regression Potential]
* If a user has manually set his own JKCS12 cacerts and didn't update
/etc/default/cacerts to set "cacerts_updates=no" (from the default
of "cacerts_updates=yes") then his custom cacerts will be converted and overwritten. Still, a copy from the previous cacert is kept at
/etc/ssl/certs/java/cacerts.dpkg-old.
[References]
[1] The default keystore is defined by the keystore.type in the
/etc/java-XX-openjdk/security/java.security file.
http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/annotate/46bd35a597eb/src/java.base/share/conf/security/java.security#l186
[2] JEP 229: Create PKCS12 Keystores by Default
http://openjdk.java.net/jeps/229
[Original bug description]
I ran into a problem after doing approximately the following on an install of Ubuntu 17.10:
sudo apt-get install openjdk-9-jdk maven ca-certificates-java
Running "mvn package" on my own project threw this error without downloading anything:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
It seems that all TLS connections fail due to missing trust anchors in Java 9!
After some investigation, I discovered that the JDK's lib/security/cacerts is a symlink to /etc/ssl/certs/java/cacerts, which is provided by ca-certificates-java package. This file appeared to be a PKCS12 file with password "changeit" protecting it. I was able to list its contents using both keytool -list -cacerts and openssl pkcs12 -in cacerts with that password, confirming that the file actually did hold the certificates. Regardless, Java 9 was not able to use the contents of this file for whatever reason.
To workaround the issue, I downgraded to openjdk-8-jdk, did rm /etc/ssl/certs/java/cacerts, then did update-ca-certificates -f, then upgraded back to openjdk-9-jdk. The old Java 8 -generated JKS file with empty string as password was usable in the Java 9, permitting mvn and other things to make TLS connections again.
The problem can be reintroduced by having java 9 installed and doing rm /etc/ssl/certs/java/cacerts and then update-ca-certificates -f.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ca-certificates-java 20170930
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64
ApportVersion: 2.20.8-0ubuntu5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 21 17:36:05 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-12-21 (0 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=fi_FI.UTF-8
SHELL=/bin/bash
SourcePackage: ca-certificates-java
UpgradeStatus: Upgraded to bionic on 2017-12-21 (0 days ago)
modified.conffile..etc.default.cacerts: [inaccessible: [Errno 13] Lupa evätty: '/etc/default/cacerts'] |
[Impact]
Any user doing a new install can be affected as soon as they install any openjdk-11 package.
[Cause]
The ca-certificate-java version 20170930 (or earlier) used OpenJDK's default keystore to create /etc/ssl/certs/java/cacerts - if the file already existed its contents were just updated without changing the keystore type.
From openjdk-9 upwards the default keystore type changed from 'jks' to 'pkcs12' [1] by means of JEP 229 [2]. A JKS keystore can be read without supplying a password (or by supplying an empty one) while a PKCS12 keystore requires a password to be set.
Thus a /etc/ssl/certs/java/cacerts created in the pkcs12 format will fail to be loaded as, by default, the truststore password is empty - in order to avoid that the user must set -Djavax.net.ssl.trustStorePassword=<passwd> or define it in /etc/java-XX-openjdk/management/management.properties. A JKS keystore will work normally, as the certificates in it can be ready when the truststore password is empty.
Ubuntu does *not* set the javax.net.ssl.trustStorePassword by default
thus any user that got a cacerts generated in JKCS12 won't be able
to use any secure connections from java.
[Test Case - Fix not applied]
Start on a new bionic install/chroot without openjdk
1. Install openjdk-11
$ sudo apt-get install openjdk-11-jdk
2. Test the keystore with an empty password (optional) and make sure it is a PKCS12
$ keytool -list -cacerts
Enter keystore password: <leave empty>
***************** 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: PKCS12
Keystore provider: SUN
Your keystore contains 0 entries
3. Test with the "changeit" password
$ keytool -list -cacerts
Enter keystore password: changeit
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 133 entries
<snipped various certs>
4. Create the java test file
$ cat <<EOF >HttpsTester.java
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
public class HttpsTester {
public static void main(String[] args) throws java.io.IOException {
HttpsURLConnection connection = (HttpsURLConnection) new URL("https://www.ubuntu.com").openConnection();
System.out.println("Response code: " + connection.getResponseCode());
System.out.println("It worked!");
}
}
EOF
5. Compile it
$ javac HttpsTester.java
6. Call it
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java HttpsTester
7. Call it again, this time set the store password
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Djavax.net.ssl.trustStorePassword=changeit HttpsTester
Response code: 200
It worked!
[Test Case - Fix applied]
Start on a new bionic install/chroot without openjdk
1. Install openjdk-11
$ sudo apt-get install openjdk-11-jdk
2. Test the keystore with an empty password (optional) and make sure it is a JKS
$ keytool -list -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
<snipped various certs>
3. Test with the "changeit" password
keytool -list -cacerts
Enter keystore password: changeit
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 133 entries
<snipped various certs>
4. Create the java test file
$ cat <<EOF >HttpsTester.java
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
public class HttpsTester {
public static void main(String[] args) throws java.io.IOException {
HttpsURLConnection connection = (HttpsURLConnection) new URL("https://www.ubuntu.com").openConnection();
System.out.println("Response code: " + connection.getResponseCode());
System.out.println("It worked!");
}
}
EOF
5. Compile it
$ javac HttpsTester.java
6. Call it
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java HttpsTester
Response code: 200
It worked!
7. Call it again, this time set the store password
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Djavax.net.ssl.trustStorePassword=changeit HttpsTester
Response code: 200
It worked!
[Regression Potential]
* Forcing ca-certificates-java to create the keystore in the old default JKS format does not cause any regressions, only forces the system to behave as it did before openjdk-9 changed the default keystore from JKS to PKCS12.
[References]
[1] The default keystore is defined by the keystore.type in the
/etc/java-XX-openjdk/security/java.security file.
http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/annotate/46bd35a597eb/src/java.base/share/conf/security/java.security#l186
[2] JEP 229: Create PKCS12 Keystores by Default
http://openjdk.java.net/jeps/229
[Original bug description]
I ran into a problem after doing approximately the following on an install of Ubuntu 17.10:
sudo apt-get install openjdk-9-jdk maven ca-certificates-java
Running "mvn package" on my own project threw this error without downloading anything:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
It seems that all TLS connections fail due to missing trust anchors in Java 9!
After some investigation, I discovered that the JDK's lib/security/cacerts is a symlink to /etc/ssl/certs/java/cacerts, which is provided by ca-certificates-java package. This file appeared to be a PKCS12 file with password "changeit" protecting it. I was able to list its contents using both keytool -list -cacerts and openssl pkcs12 -in cacerts with that password, confirming that the file actually did hold the certificates. Regardless, Java 9 was not able to use the contents of this file for whatever reason.
To workaround the issue, I downgraded to openjdk-8-jdk, did rm /etc/ssl/certs/java/cacerts, then did update-ca-certificates -f, then upgraded back to openjdk-9-jdk. The old Java 8 -generated JKS file with empty string as password was usable in the Java 9, permitting mvn and other things to make TLS connections again.
The problem can be reintroduced by having java 9 installed and doing rm /etc/ssl/certs/java/cacerts and then update-ca-certificates -f.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ca-certificates-java 20170930
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64
ApportVersion: 2.20.8-0ubuntu5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 21 17:36:05 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-12-21 (0 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=fi_FI.UTF-8
SHELL=/bin/bash
SourcePackage: ca-certificates-java
UpgradeStatus: Upgraded to bionic on 2017-12-21 (0 days ago)
modified.conffile..etc.default.cacerts: [inaccessible: [Errno 13] Lupa evätty: '/etc/default/cacerts'] |
|
| 2018-07-18 06:51:59 |
Łukasz Zemczak |
ca-certificates-java (Ubuntu Bionic): status |
Confirmed |
Fix Committed |
|
| 2018-07-18 06:52:01 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-07-18 06:52:05 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-07-18 06:52:12 |
Łukasz Zemczak |
tags |
amd64 apport-bug bionic wayland-session |
amd64 apport-bug bionic verification-needed verification-needed-bionic wayland-session |
|
| 2018-07-18 08:01:07 |
Mikael Gueck |
tags |
amd64 apport-bug bionic verification-needed verification-needed-bionic wayland-session |
amd64 apport-bug bionic verification-done-bionic verification-needed wayland-session |
|
| 2018-07-18 19:54:40 |
Julien Bonjean |
bug |
|
|
added subscriber Julien Bonjean |
| 2018-07-20 20:11:03 |
Joe George |
bug |
|
|
added subscriber Joe George |
| 2018-07-24 12:51:45 |
Mikael Gueck |
tags |
amd64 apport-bug bionic verification-done-bionic verification-needed wayland-session |
amd64 apport-bug bionic verification-done verification-done-bionic wayland-session |
|
| 2018-07-30 16:14:36 |
Launchpad Janitor |
ca-certificates-java (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-30 16:14:47 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
