Develop Reference

Missing JKS truststorestore file in 'c:\ejbca\p12\truststore.jks' while installing Ejbca on Windows

I am installing EJBCA on a Windows .
OS version: Windows Server 2016
Java: OpenJDK 8.0.242.08
Ant: ant 1.9.14
Database: MariaDB 10.4.12
Server: Wildfly 10.1.0
EJBCA Version: 6.15.2
Installation proceeded using this https://doc.primekey.com/ejbca6152/ejbca-installations/ejbca-main-installation manual.
Unfortunately on the command ant deploy-keystore provides this error:
jee:deploytruststore:
BUILD FAILED
c:\ejbca\build.xml:844: The following error occurred while executing this line:
c:\ejbca\bin\jboss.xml:310: The following error occurred while executing this line:
c:\ejbca\bin\jboss.xml:294: Missing JKS truststorestore file in 'c:\ejbca/p12/truststore.jks'
It has a corresponding error (I think they are related):
ejbca:javatruststore:
[input] skipping input as property ca.name has already been set.
[echo] Getting root certificate in DER format...
[echo] ca getcacert "ManagementCA" C:\Users\tsaForFN\AppData\Local\Temp\2\/rootca.der -der
[java] Wrote CA certificate to 'C:\Users\tsaForFN\AppData\Local\Temp\2\/rootca.der' using DER encoding.
[echo] Adding to or creating keystore: c:\ejbca/p12/truststore.jks
ejbca:javatruststore-removeold:
[exec] keytool error: java.lang.Exception: Input not an X.509 certificate
[exec] java.lang.Exception: Input not an X.509 certificate
[exec] at sun.security.tools.keytool.Main.addTrustedCert(Main.java:2861)
[exec] at sun.security.tools.keytool.Main.doCommands(Main.java:1050)
[exec] at sun.security.tools.keytool.Main.run(Main.java:366)
[exec] at sun.security.tools.keytool.Main.main(Main.java:359)
[exec] Result: 1
[delete] Deleting: C:\Users\tsaForFN\AppData\Local\Temp\2\rootca.der
I tried to change slashes but it still didn't worked.
This is the log of Wildfly server
https://controlc.com/bb5d54f4
This is the log of EJBCA installation
https://controlc.com/f6f062d2
properties are default except database which is configured, working and not relevant right now.

Your issue is this: "Input not an X.509 certificate"
This is due to your usage of "implicitlyCA" in "install.properties", creating a CA certificate that is not useable by normal clients.
Initializing CA with 'ManagementCA' 'CN=ManagementCA,O=EJBCA Sample,C=SE' 'soft' '<ca.tokenpassword hidden>' 'implicitlyCA' 'ECDSA' '3650' 'null' 'SHA256withECDSA' -superadmincn 'SuperAdmin'...
You have configured the Management CA to use "implicitlyCA" ECDSA, which is not something that Java, Windows or any web servers and browsers support.
You need to use keys (in the ca.keyspec setting) that can be used for TLS connections, such as RSA 2048 or ECDSA prime256v1.
ImplicitlyCA can only be used if you are really really really sure what you are doing, and you use specific customer client software.

The step before is ant runinstall which :
1- created the Management CA.
2-Create TLS keystores for handling HTTPS, signed by the Management CA
3-Create the key store for the initial super administrator
it might not successfully done 2nd and 3rd step.
So you need to :
delete all the date(rows) in you ejbca database in all tables
,then from $EJBCA_HOME:
ant -q clean deployear
ant runinstall
ant deploy-keystore
Inshaallah it will work

Lucee Error - java.security.cert.CertificateException: No X509TrustManager implementation available

In converting an ACF website to Lucee, we're facing some configuration issues. Our environment is Lucee5, Tomcat7, and Java.
There seems to be something not configured correctly for Lucee to be able to access an endpoint webservice via SSL. The same code works without any issues on CF9 on the same sever in a different Tomcat container.
The test call:
cfhttp(method="GET", charset="utf-8", url="https://our_lucee_server.org/wf/webservice/wf_webservice.cfc?wsdl", result="result") {
}
writeDump(result);
results in a:
java.security.cert.CertificateException: No X509TrustManager implementation available
It's been suggested that the endpoint serving the WSDL is the issue and that either Tomcat or Apache needs to be configured. Since Lucee is the program throwing the error, how can I determine what's preventing Lucee from accessing the endpoint?
The WSDL can be accessed no problem from a browser.
Things we've tried.
importing the SSL into Lucee from the target domain using Lucee server admin and restarting.
Spinning up an instance of Lucee using CommandBox, and then copying the cacerts file from CommandBox to the Lucee Server.

i think this can be solved by importing the cert for the site you are trying to access and adding it to the java home / jre / lib / security folder ...
for reasons unknown the cert for the site you are trying to access is not trusted so need to add it to trust store.

the final solution for us was running the following two commands.
this is for a CentOS7, Java 8, Tomcat, Lucee5 set up ...
step 1: back up the lucee keystore:
mv /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts.bak
(where /opt/tomcatXXX/webapps/XXX/WEB-INF/ is the path to the lucee instance)
step 2: make a symbolic link between the java keystore and the lucee keystore
ln -s /opt/tomcatxxx/conf/s2s-ubertruststore_01_10_18.jks /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts
Essentially, the keystore that came with Lucee5 didn't work out of the box.
Pointing the lucee keystore to the working Java keystore fixed it.
Step 3:
Restart Tomcat and lucee

Cannot Connect Jconsole to Websphere SSL

I am having trouble connecting WebSphere with Jconsole through an SSL connection. I have generate my own keystore and truststore with certificates and I have setup the following system properties through WebSphere:
-Dcom.ibm.team.server.monitoring.mbean.server=WebSphere -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=12099 -Djavax.net.ssl.keyStore={KEYSTOREPATH}\keystore -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStorePassword=password -Dcom.sun.management.jmxremote.authenticate=false
On the jconsole side I am running the following arguments to add the truststore files to the runtime:
jconsole -J-Djavax.net.ssl.trustStore={KEYSTOREPATH}\truststore -J-Djavax.net.ssl.trustStorePassword=password -J-Djavax.net.ssl.trustStoreType=pkcs12 -J-Djava.security.debug=all localhost:12099
With the debug mode, I am able to see the error on the client side:
java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at com.ibm.security.util.DerInputStream.getLength(DerInputStream.java:724)
at com.ibm.security.util.DerInputStream.getLength(DerInputStream.java:698)
at com.ibm.security.util.DerValue.<init>(DerValue.java:254)
at com.ibm.security.util.DerInputStream.getDerValue(DerInputStream.java:499)
at com.ibm.security.pkcsutil.PKCSDerObject.decode(PKCSDerObject.java:251)
at com.ibm.security.pkcs12.PFX.<init>(PFX.java:134)
at com.ibm.crypto.provider.PKCS12KeyStore.engineLoad(Unknown Source)
at java.security.KeyStore.load(KeyStore.java:1225)
at com.ibm.jsse2.cc.a(cc.java:72)
at com.ibm.jsse2.cc.a(cc.java:76)
at com.ibm.jsse2.ec.g(ec.java:7)
at com.ibm.jsse2.ec.<init>(ec.java:19)
at com.ibm.jsse2.ec.e(ec.java:14)
at com.ibm.jsse2.SSLSocketFactoryImpl.<init>(SSLSocketFactoryImpl.java:16)
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1617)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:37)
at javax.rmi.ssl.SslRMIClientSocketFactory.getDefaultClientSocketFactory(SslRMIClientSocketFactory.java:218)
at javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:625)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:228)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:214)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:353)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at sun.tools.jconsole.ProxyClient.checkSslConfig(ProxyClient.java:230)
at sun.tools.jconsole.ProxyClient.<init>(ProxyClient.java:133)
at sun.tools.jconsole.ProxyClient.getProxyClient(ProxyClient.java:487)
at sun.tools.jconsole.JConsole$3.run(JConsole.java:551)
Research tells me that the issue might be with the format of the keystore and truststore which in my case is PKCS12. The default is expecting JKS and I have changed this in the java.security file in the JAVA_HOME/jre/lib/security/java.security:
#
# Default keystore type.
#
keystore.type=pkcs12
Also, I have client authentication disabled.
Does anyone know what the issue might be with my setup?

SocketException Default SSL context is null while connecting to remote server

I am facing the following SSL connection exception when trying to connect to remote server:
java.net.SocketException: Default SSL context init failed: null
Most of the thread suggest that there is some problem with the keystore location that contains the certificate file.
Others like this post: Default SSL context init failed: null suggests is to create the SSL Context by yourself. But, again the issue is not resolved yet.
And here is what I did so far:
I tried to add certificate to the following file locations and all of them gave me the same error mentioned earlier:
• Cacerts file in Java Home.
• Default cacerts location for the IDE I am using (JDveloper 10.1.3.2) which is in my case : C:\JDeveloper\WorkSpace_10g\jdevstudio10132\jdk\jre\lib\security\cacerts
• New keystore that only contains this certificate.
The certificated is added using Portecle applet( I also tried keytool options from Command prompts)
I am also referring to the trustStore and keyStore in the code as follow:
System.setProperty("javax.net.ssl.trustStore", trustStore file path goes here);
System.setProperty("javax.net.ssl.trustStorePassword", password goes here);
System.setProperty("javax.net.ssl.keyStore", keyStore file path goes here);
System.setProperty("javax.net.ssl.keyStorePassword", password goes here);
In the above code the file path refer for the cacerts files mentioned earlier (Java home, default JDeveloper cacerts and newly created keystore) of course I tried each one separately.

The keystore isn't found. Check that you can open that file from within the same piece of code by the same name you're using in javax.net.ssl.keyStore.
If you're using the default cacerts you don't need to set javax.net.ssl.trustStore/trustStorePassword at all.

Weird problem using sun.security.pkcs11.SunPKCS11: The specified procedure could not be found?

I'm developing this application to be used speceifically with Firefox (it's for internal use). Basically, we're using the sun.security stuff to read Firefox's KeyStore and sign data with the certs we get.
I've tested this on several machines and the results are varying, I can't seem to pinpoint the reason.
I've tested it on the latest ubuntu release, Firefox 3.6.13, using Java version 1.6.0_22, it works there. I also have a Windows XP laptop with the same Firefox version using Java version 1.6.0_17, where it works as well.
There are 2 other Windows XP laptops that it will not work on, giving the same error. They're running the same version of Firefox and using java version 1.6.0_17.
The error is:
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:183)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
at SignedMessage.SigningApplet.initializeCrypto(SigningApplet.java:327)
at SignedMessage.SigningApplet.init(SigningApplet.java:84)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: The specified procedure could not be found.
at sun.security.pkcs11.Secmod.nssLoadLibrary(Native Method)
at sun.security.pkcs11.Secmod.initialize(Secmod.java:186)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:179)
... 5 more
Exception: java.security.ProviderException: Could not initialize NSS
From what I can tell it can't find the native nssLoadLibrary routine? The configuration file is pointing it to the Firefox install directory (where it can grab the nss3.dll or libnss3.so file). It does this across all pc's and all the paths in the configuration seem to be valid.
A sample config file, for what it's worth:
name=NSS
nssDbMode=readOnly
nssModule=keystore
nssSecmodDirectory="C:\\Documents and Settings\\user\\Application Data\\Mozilla\\firefox\\Profiles/8bzd2qqm.default"
nssLibraryDirectory=C:\Program Files\Mozilla Firefox
I was hoping someone would have a clue, or maybe some tips on getting further with debugging. I'm at a loss here.

I'm likely much too late for this to be of use to you, but I was having similar problems, and adding dist\WINXXX_DBG.OBJ\lib to my PATH resolved this issue.

Quick answer: Use the x86 jdk not the x64 jdk with NSS and JSS
Quick test against a NSS certificate database:
keytool -list -v -storetype pkcs11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg NSS_CONFIG_FIPS
where NSS_CONFIG_FIPS is the path to a config file pointing to an NSS database. This command will fail with a stack trace that matches the questioners error if it is a JDK issue and succeed if the JDK is configured properly (and if the config file is correct)
Note that my stack trace included the message:
Caused by: java.io.IOException: %1 is not a valid Win32 application.
I ran dumpbin /headers on the NSS dlls and found that the Mozilla built binaries are all 32 bit. I installed the x86 jdk and repointed JAVA_HOME. Everything began working.
To Vivek's point, NSS and the accompanying executables are very sensitive to the presence of the libraries. Be sure all of the .dll, .lib, and .chk files are present on the path. In particular, modutil.exe will fail certain commands without the chk files and the error messages are not helpful. Your NSS lib folder will need to include the NSS and NSPR lib folders, the jss4.dll and jss4.lib files, and the jss4.jar.
Also note that if you build NSS yourself, the libaries will not be signed with an approved code signing cert which will cause problems with JCA.