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());
Related
When connecting via a java API service to a remote server by https I got the following exception
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The server is a Windows Server 2012 which has the corresponding wildcard certificate installed as root certificate too.
I've used keytool to import that exact same certificate to the keystore called cacerts, so the jvm is using it to prevent the exception above.
As keytool shows, the certificate is installed correctly but the handshake exception still occurs when connecting to the server.
I've checked the windows environment variables on the server and found out that the JAVA_OPTS is missing.
Even tried restarting the entire server but this did not help either.
In order to get it work, do I need to add the environment variable manually referencing the keystore as shown below?
-Djavax.net.ssl.trustStore=C:\path\to\cacerts
I was able to fix this issue by adding the certificate to the java applications keystore too.
Apologies for yet another "unable to find certificate" question.
I'm developing on a Windows 7 machine. I am using multiple Java versions and because of that am explicit about paths to the used java version (here Java6). I achieve this by the following two lines:
set path=c:\Program Files\Java\jdk1.6.0_45\bin;%path%
set java_home=c:\Program Files\Java\jdk1.6.0_45
I need to use a 3rd party web service https://service.gov/Service.svc?wsdl that provides a certificate.PFX certificate (both service URI and certificate file are renamed as a way to protect the 3rd party's interests). I have made sure that after importing the certificate file in Windows I can open the WSDL file in my browser.
I first import the certificate in my keystore (using Administrator Command Prompt to get access to write in the system folder):
keytool -importkeystore -srckeystore certificate.pfx -srcstoretype pkcs12 -keystore "c:\Program Files\Java\jdk1.6.0_45\jre\lib\security\cacerts"
I get a success notification. Still, I make sure that the new certificate is present in the output of:
keytool -list -keystore "c:\Program Files\Java\jdk1.6.0_45\jre\lib\security\cacerts"
Then I create a new folder containing blank subfolders called src and classes. Once this is done, I run wsimport from that new folder (using Java class instead of binary to make sure I am explicit about the truststore being used):
java -classpath "c:\Program Files\Java\jdk1.6.0_45\lib\tools.jar" -Djavax.net.ssl.trustStore="c:\Program Files\Java\jdk1.6.0_45\jre\lib\security\cacerts" -Djavax.net.ssl.trustStorePassword=changeit com.sun.tools.internal.ws.WsImport https://service.gov/Service.svc?wsdl -s src -d classes
The output is the following:
parsing WSDL...
[ERROR] sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Failed to read the WSDL document: https://service.gov/Service.svc?wsdl, because 1) could not find the document; /2) the document could not be read; 3) the root element of the document is not <wsdl:definitions>.
[ERROR] failed.noservice=Could not find wsdl:service in the provided WSDL(s):
At least one WSDL with at least one service definition needs to be provided.
Failed to parse the WSDL.
The WSDL file contains and is used by other organisations, so the problem is pretty certainly not on the 3rd party's side.
Am I missing something? To me it all seems obvious by now, but it still doesn't work. I have also tried this with Java8, and the result is pretty much the same. The only difference is that in Java8, the WsImport class no longer exists, so I am using the wsimport.exe binary.
Thanks in advance for any ideas or hints.
The pfx file (which contains a certificate and also a private key) is for client authentication, while a truststore is for validating the server certificate. It is important to understand the difference between a keystore and a truststore.
You have imported the client certificate (and key) into the default truststore (cacerts). What you should have done instead is:
Import the issuer (CA) of the SSL certificate of the server into cacerts. You can skip this step if the CA certificate is already in cacerts, which is probably the case here.
Use the pfx file as your keystore for client authentication. The easiest way is to convert it to jks: https://stackoverflow.com/a/3054034/2672392 The properties to pass to wsimport are "javax.net.ssl.keyStore" and "javax.net.ssl.keyStorePassword".
See this answer for a list of important SSL properties: https://stackoverflow.com/a/5871352/2672392
I successfully installed a GoDaddy SSL certificate in Tomcat last year.
When the certificate expired, I renewed it. I did this without generating a new keystore or CSR. GoDaddy delivered three files to me, gd_bundle.crt, gd_intermediate.crt, and a third .crt file with a random number as the name.
I don't know what to do next. I assume I have to incorporate these files into my existing keystore. GoDaddy provides this help page:
http://support.godaddy.com/help/article/5355/ssl-certificate-renewal-tomcat-4-x5-x6-x
The page says I can do this one of two ways. I tried the first way and all I got was an error message saying "-inkey: no such file or directory". I tried the second way, but I do not have any file with the name it references, and also any attempt to import the new certs into the existing keystore results in an error "certificate not imported, alias already exists".
What is the correct way to update my keystore file with the new certificate?
Thanks.
You need to use the keytool to import the numbered file into the existing KeyStore, using the same alias you're already using, with the -importcert option.
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.
I have a valid keystore on my local development machine, which contains a certificate for accessing a webservice via HTTPS.
I access this keystore in my project via:
System.setProperty("javax.net.ssl.truststore", "C:\\<workspaceprojectPath>\\SIPkeystore\\truststore.jks"); // sollte wohl auch ohne Keystore klappen
System.setProperty("javax.net.ssl.keyStore", "C:\\<workspaceprojectPath>\\SIPkeystore\\SIPkeystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "SECRET");
Now I want to access that certificate from another project. There I provide the same (full) path to the keystore in the other (local) project directory.
Apparently the path is still found by the jvm and the property is being set, but on accessing the web service I get the same error message as if I hadn't added the keystore at all.
When trying run the application I get a
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
Is there a possibility to copy an existing keystore? This will be important also, when we deploy the application to our server. The application will run as stand-alone jar. (no web server)
EDIT:
Ok, copying the keystore does not seem to be the problem, as I am able to run the original application while using a local copy of the original keystore files. It seems like it is a configuration issue.
Is there a possibility to copy an existing keystore?
Yes. From the file system perspective it is just a file.
I imagine that the problem is one of the following:
The relevant properties are not correctly set in the other project.
The other JVM cannot find the keystore file (e.g. because of chrooting or some such)
The other JVM doesn't have the required permissions to access/read the keystore file.
The read access is being blocked by (for instance) SELinux.
First of all, if Web service doesn't require client certificate (i.e. that you introduce yourself) there's no need for keystore - you only need truststore.
It could be that other project cannot access truststore, so just for exercise, try to open C:\<workspaceprojectPath>\SIPkeystore\truststore.jks there and read first few bytes. If you succeed, it means that the other project has some other truststore set as default, so in that case try:
System.out.println(System.getProperty("javax.net.ssl.trustStore"));
Also, bear in mind that Java is case-sensitive, and you specified javax.net.ssl.truststore property instead of javax.net.ssl.trustStore. Try fixing this also.
The valicert class 3 CA certificate is not in your default truststore (which is probably the cacerts file in your JRE lib/security directory, but see the JSSE documentation for the full story).
I think you should create your own truststore file (which can be a copy of the cacerts file) and add the valicert root ca to this. Then point to this file with the javax.net.ssl.trustStore system property.