We Keep Coding

Client Authentication Tomcat - trustAnchors parameter must be non-empty

I know this question appears no stackoverflow a lot, and the exception is to do with a missing truststore - but here is my issue:
Using Apache Tomcat v7.0.56 as server on Windows with Java 8.0.71
modified tomcat/conf/server.xml to include SSL Connector with truststoreType="PKCS12", truststoreFile="conf/regtomcat.truststore" truststorePass="password"
I launch tomcat and I know it is reading this truststore file correctly as I originally did not have the file in pkcs12 format and tomcat reported an error on startup. I also have tried breaking the file location just to see tomcat startup fail as it can not find the file. So tomcat launches okay - it is reading the truststore which must mean it exists and can be read.
I load a p12 file into my browser certificate, and go to my application URL. I then get the tomcat error:
handling exception: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty
Given that my trustore exists, and contains my certificate - what could the problem be?
I generated all certificates and truststores using keytool. The truststore was created using the command
keytool -importcert -alias regClient -storetype PKCS12 -keystore regtomcat.truststore -file regClient.cer

One probable reason might be that if we use same .jks file as a keystore and as a truststore, then the server start up is failing with following error : java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty.
Keystore is to store the ServerCerts and TrustStore is to store the CA certs. On adding at least one CA certificate in the .jks, above issue will be resolved.

Okay - the problem was the certificate was created using JDK 1.8 and the tomcat was running with JRE 1.7 - for whatever reason this caused an issue, so the fix was to use JRE 1.8 and now everything works okay.

Faced same issue. My keystore only had private key pair of the website. Imported the public certificates from the key pair all the way down to the root and it worked.

Faced same issue. The cause was far more basic: the .jks file must be readable for the account under which tomcat service runs. Though we have it as a systemctl service (hence started/stopped from root) the account was tomcat, so a simple chown tomcat:tomcat for the .jks store did the job!

For me the issue was I was passing null to the keyword as password wherein the password was changeit
ks.load(fis, "changeit".toCharArray());

Java applets and setting up an exception for a PC that is not a web server

I have being trying to get a clock applet to run on my locate PC outside of netbeans but the when I load the web page to run the applet I get “Application Blocked by Java Security”. Googling I then create a self-signed certificate thinking that would solve the problem.
I opened a command window and changed directory to where the jar and class were and the created the key and certificate.
cd C:\DEV\clock\classes
C:\Program Files\Java\jdk1.8.0_45\bin\keytool" -genkey -alias selfsigned -keyalg RSA -keysize 2048 -validity 365 -keystore keystore.jks
Enter keystore password: <password>
Re-enter new password: <password>
What is your first and last name?
[Unknown]: PC129.aa.dfdd.nasa.gov (this is fake but matches the pattern I used)
Etc.
C:\DEV\NelsonsPrograms\clock\clock\classes>"C:\Program Files\Java\jdk1.8.0_45\bin\keytool" -selfcert -keystore keystore.jks -alias selfsigned -validity 3650
Enter keystore password: <password>
C:\DEV\NelsonsPrograms\clock\clock\classes>"C:\Program Files\Java\jdk1.8.0_45\bin\jarsigner" -keystore keystore.jks threeClock.jar selfsigned
Enter Passphrase for keystore: selfsigned
jar signed.
Warning:
No -tsa or -tsacert is provided and this jar is not timestamped. Without a times tamp, users may not be able to validate this jar after the signer certificate's expiration date (2025-06-21) or after any future revocation date.
I this tried to start the web page again but this time I got “Application Blocked. Your security settings have blocked a self-signed application from running”. I again googled and they all seem to basically say that you need to still add a Java exception for you PC to make the applet run. But all the examples seem to be www.foo.com examples with either a full path name to the web/applet directory, domain name, or full domain name which all seem to be www or http addresses. So what is the correct input for a PC that is not a web server or has a www address setup for it? I don’t think I need the full path to the applet directory included in the exception name since I only saw that in one example.
So lets say this is my PC info: PC129 is the host name. Network: aa.dfdd.nasa.gov
So what should the the exception name be?
The SAs here have no idea since they always add exceptions for web servers that have www web addresses.

The SA finally came by and after lots of combinations we found that adding the following exception to the java site list will allow the applets to run.
file:/C:/DEV/NelsonsPrograms/clock/clock/classes/
The full path name was required to the location where the applet and web page was located otherwise the applet would be blocked.

Correction, while the signed jar is running correctly, web pages that try to just run the XXX.class don't run. The applet is displaying the layout, but nothing is running in it. I think the local input file is being blocked so there is no data to display. So make a jar, self sign it, and run the jar from the web page.

I turned on the java console via Java Control Panel - Advanced tab to see why the aosClock.class version didn't work while the signed clock.jar did and as you can see it’s the security stuff again stopping the applet from working. It’s stopping the applet from reading in the clock time data. Googling seems to indicate that I would have to insert grant code into the applet, but since the signed jar version works fine on my PC I will use that to test. I don't want to add extra stuff that is not needed in the applet when running on a real web server. The jar way also seems to be the standard way to do web applets now anyway.
aosClock: Thread-14: Forcing garbage collection...
Exception in thread "Thread-14" java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\DEV\NelsonsPrograms\clock\clock\classes\aqua_aos_times" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkRead(Unknown Source)
at java.io.File.isDirectory(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.initializeHeaders(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.getLastModified(Unknown Source)
at singleClock.run(aosClock.java:679)

Can't load a JKS keystore containing

I'm trying to load a JKS keystore containing an intermediate CA certificate acquired from an existing web server.
The Verisign certificate is shown below.
-----BEGIN CERTIFICATE-----
MIIF5DCCBMygAwIBAgIQW3dZxheE4V7HJ8AylSkoazANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMTYxMTA3MjM1OTU5WjCBujEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE0MDIGA1UEAxMrVmVy
aVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBDQTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJjboFXrnP0XeeOabhQdsVuYI4cWbod2
nLU4O7WgerQHYwkZ5iqISKnnnbYwWgiXDOyq5BZpcmIjmvt6VCiYxQwtt9citsj5
OBfH3doxRpqUFI6e7nigtyLUSVSXTeV0W5K87Gws3+fBthsaVWtmCAN/Ra+aM/EQ
wGyZSpIkMQht3QI+YXZ4eLbtfjeubPOJ4bfh3BXMt1afgKCxBX9ONxX/ty8ejwY4
P1C3aSijtWZfNhpSSENmUt+ikk/TGGC+4+peGXEFv54cbGhyJW+ze3PJbb0S/5tB
Ml706H7FC6NMZNFOvCYIZfsZl1h44TO/7Wg+sSdFb8Di7Jdp91zT91ECAwEAAaOC
AdIwggHOMB0GA1UdDgQWBBT8ilC6nrklWntVhU+VAGOP6VhrQzASBgNVHRMBAf8E
CDAGAQH/AgEAMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRw
czovL3d3dy52ZXJpc2lnbi5jb20vY3BzMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6
Ly9FVlNlY3VyZS1jcmwudmVyaXNpZ24uY29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB
/wQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZ
MFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7
GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nby5naWYwKQYDVR0R
BCIwIKQeMBwxGjAYBgNVBAMTEUNsYXNzM0NBMjA0OC0xLTQ3MD0GCCsGAQUFBwEB
BDEwLzAtBggrBgEFBQcwAYYhaHR0cDovL0VWU2VjdXJlLW9jc3AudmVyaXNpZ24u
Y29tMB8GA1UdIwQYMBaAFH/TZafC3ey78DAJ80M5+gKvMzEzMA0GCSqGSIb3DQEB
BQUAA4IBAQCWovp/5j3t1CvOtxU/wHIDX4u6FpAl98KD2Md1NGNoElMMU4l7yVYJ
p8M2RE4O0GJis4b66KGbNGeNUyIXPv2s7mcuQ+JdfzOE8qJwwG6Cl8A0/SXGI3/t
5rDFV0OEst4t8dD2SB8UcVeyrDHhlyQjyRNddOVG7wl8nuGZMQoIeRuPcZ8XZsg4
z+6Ml7YGuXNG5NOUweVgtSV1LdlpMezNlsOjdv3odESsErlNv1HoudRETifLriDR
fip8tmNHnna6l9AW5wtsbfdDbzMLKTB3+p359U64drPNGLT5IO892+bKrZvQTtKH
qQ2mRHNQ3XBb7a1+Srwi1agm5MKFIA3Z
-----END CERTIFICATE-----
I have imported the certificate into a JKS keystore using the following command:
keytool -importcert -trustcacerts -alias vs -file vs.cer -keystore vs.jks -storepass changeit -storetype JKS
I have verified that keytool can read the certificate details back from the newly created keystore.
Finally, I am using the following Java code to load the keystore:
final KeyStore trustStore = KeyStore.getInstance("JKS");
trustStream = getClass().getClassLoader().getResourceAsStream("vs.jks");
trustStore.load(trustStream, "changeit".toCharArray());
Currently using JDK 1.7.0_51.
Unfortunately, an exception is thrown while in the load() method.
java.security.cert.CertificateParsingException: java.io.IOException: X500 RDN
at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:171)
at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1788)
at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:202)
at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:97)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:747)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1214)
...
Caused by: java.io.IOException: X500 RDN
at sun.security.x509.RDN.<init>(RDN.java:242)
at sun.security.x509.X500Name.parseDER(X500Name.java:804)
at sun.security.x509.X500Name.<init>(X500Name.java:307)
at sun.security.x509.CertificateIssuerName.<init>(CertificateIssuerName.java:82)
at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:685)
at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:169)
... 37 more
Am I doing anything wrong?
I have the feeling that there is something unexpected in the certificate which is confusing the parser. The stack trace suggests that there may be a problem parsing the issuer name.
Is there anything I can do to work around this?

I have figured out the cause. Nothing wrong with the certificate file or the keystore!
I'm using Maven to compile my project, which is automatically copying the jks file to the target build directory.
It turned out that, during the copying process, Maven assumed the file was a text file, and "helpfully" converted any extended ASCII characters (>= 0x80) to '?' (0x3F)!
When analysing / listing the JKS file, I naturally only looked in my source directory and never thought to verify that the resource file be identical in content!
Confirms the golden rule, Never Trust Maven!
I solved this by adding the following to my pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<configuration>
<nonFilteredFileExtensions>
<nonFilteredFileExtension>jks</nonFilteredFileExtension>
</nonFilteredFileExtensions>
</configuration>
</plugin>

I recently had this same exception:
java.security.cert.CertificateParsingException: java.io.IOException: X500 RDN
I had a little look back in the history of our mercurial repo and it is pretty clear that a merge was done of various keystores when changes from a similar repo (different release) were pulled in. The outcome was that all of those keystores that were "merged" were in fact corrupted.
A manual copy of the affected files between the repos resolved the issue.

InvocationTargetException when using AccessControler.doPrivileged in a signed applet

I'm having the following method in an applet which is called via JavaScript
public String getAString()
{
Object rc = AccessController.doPrivileged(
new java.security.PrivilegedAction()
{
public Object run()
{
try
{
return "OK";
}
catch (Throwable t)
{
t.printStackTrace();
return "ERROR: " + t.getMessage() + " " + t.getCause();
}
}
});
// Return value
return rc.toString();
}
The applet is signed using a certificate created with keytool
When I call getAString() if throws the InvocationTargetException.
If I call other methods which don't use the AccessController class, I'm not having this problem.
Also, each time I open the browser I'm asked to allow the applet to run even the the applet is signed.
How can I fix this?
edit
I added a button and now I'm getting more info:
signer information does not match signer information of other classes
in the same package
I'm using a third party archive. In the original form is unsigned, but I signed it using the same cert (although with different commands).
edit 2
Here is how I sign the jars
keytool -genkey -keystore vkeystore -keyalg rsa -dname "CN=XXX, OU=XXX, O=XXX, L=Atlanta, ST=GA,C=NL" -alias printer -validity 3600 -keypass XXX-storepass XXX
jarsigner -keystore vkeystore -storepass XXX -keypass XXX -signedjar JSPrintS.jar JSPrint.jar printer
jarsigner -keystore vkeystore -storepass XXX -keypass XXX -signedjar jPDFPrintS.jar jPDFPrint.jar printer
JSPrint.jar contains the applet
edit 3
the applet definition is (located in JSPrint.jar)
package Eplatforms;
import java.net.URL;
import java.security.AccessController;
import javax.swing.JApplet;
import java.awt.event.*;
import java.awt.*;
import com.XXX.pdfPrint.PDFPrint;
public class JSPrint extends JApplet implements ActionListener
....
jPDFPrint.jar is a third party jar
EDIT 4
I tried to minimize the problem a bit and I found out that when calling AccessControler.doPrivileged from a jar file (even signed one), I get the following exception:
Exception in thread "main" java.lang.NoClassDefFoundError: TestPrivileges$1
at TestPrivileges.getAString(TestPrivileges.java:14)
at TestPrivileges.main(TestPrivileges.java:7)
Caused by: java.lang.ClassNotFoundException: TestPrivileges$1
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Here is a testing class:
http://pastebin.com/EgmdwuqL
Notice that calling other methods doesn't raise this exception.
Here is how I compile and run it:
javac TestPrivileges.java
java TestPrivileges
jar cvf TestPrivileges.jar TestPrivileges.class
jarsigner -keystore vkeystore -storepass My0Company -keypass My0Company -signedjar TestPrivilegesS.jar TestPrivileges.jar printer
copy TestPrivilegesS.jar x /Y
copy TestPrivileges.jar x /Y
cd x
java -classpath TestPrivilegesS.jar TestPrivileges
java -classpath TestPrivileges.jar TestPrivileges
cd ..
A quick for vkeystore:
keytool -genkey -keystore vkeystore -keyalg rsa -dname "CN=MyCompany, OU=MyCompany, O=MyCompany, L=Atlanta, ST=GA,C=NL" -alias printer -validity 3600 -keypass My0Company -storepass My0Company
The first run works ok (probably because the class file is in the same directory).
Then I create to archives, one signed and another unsigned. When I run them, I got those errors. Notice the jars are in a separate folder which contains only those jars and no class file.

I am with Andrew on this.
I've created an app that should help us find the code signing issue.
https://gist.github.com/2596125
(Since we don't want to Spam Andrew I've created this.)
With more information that finally came out it seems that you are not packing the TestPrivileges$1 class with the jar.
To fix this do this for jar packing:
jar cvf TestPrivileges.jar TestPrivileges.class TestPrivileges$1.class

New theory
The 3rd party Jar was already signed when it was signed it with your certificate. Now there are 2 lots of information on digital keys inside the Jar, which is confusing the JRE.
Either use the original Jar, as it was, or remove the digital signatures and sign it again with your own certificate.
Earlier answer
signer information does not match signer information of other classes in the same package
The actual error is because two jars are considered to be signed with different certificates, even I'm using the same certificate.
I suspect that the problem comes down to the part of the error/comment that I made bold.
Classes in the same package must be in the same Jar.

PKCS#12 : DerInputStream.getLength() exception

I generate a certificate using the keytool command:
keytool -genkeypair -alias myRSAKey -keyalg RSA -keysize 1024 -keystore test.p12 -storepass test -storetype pkcs12
Then if I try to load it using java security API, after getting the file as a byte[] :
KeyStore ks = KeyStore.getInstance("PKCS12");
try{
ks.load(new ByteArrayInputStream(data), "test".toCharArray())
} catch (Exception e){
...
}
I get a DerInputStream.getLength(): lengthTag=127, too big exception.
What is wrong?

I had this problem and I've searched the depths of google and still couldn't find the answer. After some days battling with a terrible quality legacy code, I found what was causing this error.
KeyStore.load(InputStream is, String pass);
this method takes an InputStream and if there's any problem with such InputStream, this exception is thrown, some problems that I've encountered:
The InputStream points to the wrong / blank / just created file
The InputStream is already open or something else is holding the resource
The InputStream was already used and read, thus the position of the next byte of InputStream is it's end
The last one was the responsible for my problem. The code was creating an InputStream from a certificate, and proceeding to use it in two KeyStore.load() calls, the first one was successful, the second one always got me this error.

For others with a similar problem:
"keystore load: DerInputStream.getLength(): lengthTag=109, too big."
For me solution was to remove the param: -storetype pkcs12
since the standard type is jks

Probably the certificate you create has an extra character at the end which is misinterpreted to be another certificate.
Use one or more blank lines at the end.
Refer: Java Certificate Parsing

My issue (lengthTag=109, too big) was the .p12 file actually is JKS format and not PKCS # 12 format. Someone renamed the file extension. By regenerating in proper PKCS format resolved the issue.
java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:599)
at sun.security.util.DerValue.init(DerValue.java:365)
at sun.security.util.DerValue.<init>(DerValue.java:320)
at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914)
at java.security.KeyStore.load(KeyStore.java:1445)
To check the format of a security file, may use KeyStore Explorer to open the file. The left bottom bar shows the actual format.

Specify the type of certificate in the code
for eg:
System.setProperty("javax.net.ssl.trustStoreType", "jks");
System.setProperty("javax.net.ssl.keyStoreType", "pkcs12");

This happened to me in Android Studio after AndroidX migration and using the new testing framework. Even deleting the existing ~/.android/debug.keystore was failing for me
The solution was regenerate it manually (accept all questions as empty and say yes at the last one)
$ keytool -genkey -v -keystore debug.keystore -storepass android -alias androiddebugkey -keypass android -keyalg RSA -keysize 2048 -validity 10000
And copy it
$ rm ~/.android/debug.keystore
$ cp debug.keystore ~/.android/debug.keystore

This happened to me because I had copy and pasted the .p12 file locally on my windows 10 machine. No clue how/why this is a problem, but when I clone a project that has .p12 files and point my code to them, the files work. However, copy and pasting the files in windows file explorer to somewhere else on the harddrive causes this error!!!!

I had the same issue.
My solution is to replace PKCS12 with jceks in the line below because I was apparently using the wrong type.
KeyStore clientStore = KeyStore.getInstance("PKCS12");

You are doing something wrong.
I tried your command and then loaded the p12 just fine.
The following code works:
FileInputStream fin = new FileInputStream("..\\test.p12");
KeyStore ks = KeyStore.getInstance("PKCS12");
ks.load(fin, "123456".toCharArray());
System.out.println(ks.getCertificate("myrsakey"));
I was wondering if you put the command as is you get an error from keytool that the password must be at least 6 characters.
You did not get that error? What version of java are you using?
Note:if you need to create certificates you can also look into this tool.
http://sourceforge.net/projects/certhelper/

Make sure the scope of the inputstream variable is only to the method where you’re declaring it but not as static/class variable.This way this exception can be avoided.
Reason : Inputstream is not getting closed after the first time of loading certificate or data in it while it is declared as class variable.so make it available only to method.

This happened to me because the following command:
openssl pkcs12 -export -in import.pem -inkey myhost.key.pem -name shared > server.p12 (from https://docs.oracle.com/en/database/other-databases/nosql-database/12.2.4.5/security/import-key-pair-java-keystore.html)
generated a wrongly formatted pkcs12 file. Using the following corrected the problem:
openssl pkcs12 -export -in import.pem -inkey myhost.key.pem -name shared -out server.p12

This error has multpile causes... The log can be realy confusing.
One main cause can be maven filtering.
According to maven official documentation
Warning: Do not filter files with binary content like images! This will most likely result in corrupt output.
Our .jks was corrupted by maven during packaging stage.
This thread helped me to figure it out.
We can exclude some directories or file extensions from filtering directly in concerned pom.xml :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>${maven-resources-plugin.version}</version>
<configuration>
<nonFilteredFileExtensions>
<nonFilteredFileExtension>jks</nonFilteredFileExtension>
<nonFilteredFileExtension>p12</nonFilteredFileExtension>
</nonFilteredFileExtensions>
</configuration>
</plugin>