Followed steps to integrate Worklight with backend system. In 5.0.6 adapters should support mutual SSL.
Import cert into default.keystore with alias named cert1
Modified adapter's sslCertificateAlias as cert1
When using Worklight Studio to run deployed adapter connecting with server, it is complaining about "Unable to find certificate chain with alias: 'cert1'".
What are the steps missing?
Check "ssl.keystore.*" properties in "worklight.properties" file, after it check if the cert exists in the keystore file using keytool:
keytool -list -keystore default.keystore
Here is are steps to configure mutual SSL between adapter and backend server with self signed certificates:
generate adapter's private key in "default.keystore" and export its public certificate
import adapter's certificate into backend truestore file
in case backend hasn't CA signed certificate:
generate backend's private key in its keystore file and export public certificate
import backend's public certificate into "default.keystore" file on WL server
Check worklight.properties file. Make sure that ssl related setting point to a default.keystore.
Figured out yesterday. Have to config certificate chain in proper way.
All certifications (server cert, first level cert and root cert) have to combine into one in special order and import with private key into keystore. Then use one alias name so that Worklight adapter could find it.
Related
In NiFi, how does one create the necessary keystore, truststore and certificates needed to configure the StandardRestrictedSSLContextService controller service?
I need to invoke an HTTPS REST service. (Using NiFi 1.9.2 in local development mode)
Steps taken:
Used TLS toolkit to generate self-signed certs, truststore and keystore
Saved the API endpoint certificate to a .cer file (exported from chrome)
$keytool -import -alias mycert -keystore /opt/nifi/conf/truststore.jks -file api-cert.cer
After doing this, InvokeHTTP processor in NiFi indicates it cannot find the certification path:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
You can either create those files manually (using tools like openssl and keytool), use the NiFi TLS Toolkit, or obtain those files from an enterprise security team. The keystore needs to contain the private key and public certificate of the NiFi certificate; the truststore should contain the public certificates of the external services you want to interact with. See the NiFi Walkthroughs for examples. RestrictedSSLContextService is only required for incoming connections; SSLContextService can be used for outgoing connections to legacy systems (Restricted disables TLS protocol versions older than TLS v1.2).
Provide a full path in the keystore and truststore filename fields.
I'm using a nifi contianer and the default directory is /opt/nifi/nifi-current/.
I placed the files in a certs directory so my keystore filename field looks like this:
certs/keystore.pfx
I have a xmpp server (openfire 3.9.3) and trying to secure my non-ssl connection to ssl connection.
that's why i have created a self-signed certificate using java keytool as
keytool -genkey -keystore keystore -alias example.com
and i filled the several pieces of information required for the certificate.
the certificate successfully created. and i configured my server to access the keystore file but when restart my xmpp server it says
Unable to access certificate store. The keystore may be corrupt
what should i do for fixing the same issue ?
thanks in advanced
You can :
Delete certs in AdminWEB interface.
Restart openfire
Delete /opt/openfire/resources/security/keystore file
Generate new cert from web interface.
References : http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ssl-guide.html
Hope this help...:)
I am consuming third party web service in my application. It has https url which requires handshake. I am using Weblogic application Server and I want to configure the certificate in my server.
Can anyone please provide me steps to configure that certificate?
Also What is Identity and Trust on Weblogic Console?
Please help!!
Update the cacerts file for the JVM used by WebLogic. Using the WebLogic console, select the server. Then use the Configuration > Keystores tab to find the cacerts file location labeled Java Standard Trust Keystore on this page.
You will want to import the certificate from the web service into this cacerts file. If you are a Windows user, I use a free tool called Keystore Explorer (http://keystore-explorer.sourceforge.net/). This application allows to directly import the certificate using the URL. Do this by opening your cacerts file in KeyStore Explorer then use the Examine SSL option to import the certificate.
I resolved this by using keytool command provided in Jdk bin folder.
I just went to demotrust.jks and imported the third party certificate in it and it worked for me.
I used below command.
${ORACLE_HOME}/product/jrockit-jdk1.6.0_20-R28.1.0-4.0.1/bin/keytool -import -alias [AliasForYourCertificate] -keystore ${ORACLE_HOME}/Middleware/wlserver_10.3/server/lib/DemoTrust.jks -file /home/oracle/[YourCertFile].crt
I have no problem to set up SoapUI mock service with self signed certificate by following the steps at
http://www.soapui.org/Service-Mocking/securing-mockservices-with-ssl.html .
But now I want to test the mock service with a "real" certificate issue by Entrust Certification Authority - L1C.
Other information for this certificate is
Ensures the identity of a remote computer
1.2.840.113533.7.75.2
2.23.140.1.2.2
It is valid until 2016.
I used the command to import the certificate to server.keystore .
c:\Program Files\Java\jre6\bin\keytool.exe -import -alias server -keystore server.keystore -storepass mypasss -file server_cer_issued_by_entrust.cer
(if I replace server_cer_issued_by_entrust.cer with a self signed (created) certificate it works)
I got the error in SoapUI which says ssh handshake error.
I just realize that it maybe not possible since the mock service is 127.0.0.1 but the actual certificate is issue for a web service like "mydomain.com", is that right?
SOAPUI runs over java, and when java connects to SSL url performs two validations:
Validate that the server certificate is trusted.
Validate that the common name in subject distinguished name of the server certificate matches the domain.
I assume that the first validation pass since in the link instructions which you provide its specify the same keystore in mock service for both: keystore and truststore, and since server certificate is imported in this one there is no problem to pass this validation.
So probably as you said the problem is that your mock service is on 127.0.0.1 and your certificate is issued to be used in mydomain.com.
A possible workaround is to disable SSL validation however this has no sense since as you said in the question you want to test the service with "real" certificate, instead maybe you can try editing host file and adding the mapping for 127.0.0.1 ip address for your certificate server domain, in your case:
127.0.0.1 mydomain.com
And then change the SOAPUI endpoint for your mock service to https://mydomain.com.
Hope this helps,
I am trying to prepare for the switch in the SSL certificate vendors.
For the the SSL validation, Our Tomcat web application uses a JKS file created from a DigiCert certificate ( *.cer files). Our company is now switching to VeriSign next week. Since they have already provided the new *.cer files, can I simply add the new cert ( using keytool) to the existing JKS so that it works for both certificates. I am trying to avoid any downtime during the switch and prepare the server beforehand?
Any helps will be much appreciated.
You must install the certificate onto the same keystore you created the CSR from as the private key resides there. Otherwise it will not work. Please reference the article below on instructions on how to import into a tomcat server:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR234&actp=search&viewlocale=en_US&searchid=1369174910074