I am trying to integrate CAS on Liferay.
I have separate CAS server running in secure port but i am using self-signed certificate
I have a Liferay-6.1 in another server bundled with glassfish-3.1.1 server.
I have imported required key file from CAS server using java keytool in server where Liferay is hosted
But I keep getting SSL error while trying to integrate from liferay CAS configuration page.
In my opinion, here glassfish is to be blamed because I have successfully configured and tested the same CAS server in Liferay-6.1 bundled with jboss-7.0 and also tested in liferay6.1 bundled with tomcat.
I tested all liferay bundles in the same server which means there is no error in importing certificate keys.
does anybody have anyidea how can I successfully configure secure CAS in liferay bundled with glassfish?
EDIT:
I traced the error and it is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I remember this particular error while configuring self signed certificate before importing keys in other liferay bundles (jboss and tomcat). But it was gone after I imported CAS keys in keystore.
I copied from my comment:
Which keystore did you import the cert into on glassfish? There are two in the domain/config directory on glassfish, cacerts.jks and keystore.jks. Did you point the glassfish ssl listener at the new cert's alias?
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'm trying to send email using MailKit through provider's SMTP server using valid Let's Encrypt Authority X3 certificate. On Windows everything works great, but when sending from Ubuntu I get certificate error:
MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection.
One possibility is that you are trying to connect to a port which does not support SSL/TLS.
The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
The server is using a self-signed certificate which cannot be verified.
The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. (I believe this is my problem?)
The certificate presented by the server is expired or invalid.
When I dig deeper into X509Chain status it says
RevocationStatusUnknown unable to get certificate CRL
Up until now I've been ignoring this error, but I'd rather have the underlying problem fixed and I don't know what exactly I'm missing. Thanks.
If you are running your .NET application on Mono, there's a Mono FAQ that explains how to import root certificates into your certificate store: https://www.mono-project.com/docs/faq/security/
If you are using .NET Core CLR, you might find this answer helpful: Trusted Root Certificates in DotNet Core on Linux (RHEL 7.1)
I have created a Weblogic 12c Domain with a Managed Server on which i have installed SOA Suite 12.2. To be able to invoke REST services over SSL in my composites i have create a truststore with a valid certificate chain to connect to the REST server over SSL.
I have created a Custom Identity and Custom Trust for the SOA Managed server using a Custom Identity Store in /u01/data/keystores/identitykeystore.jks and truststore in /u01/data/keystores/truststore.jks.
When invoking the composite using the REST service i get a remotefault
<bpelFault><faultType>0</faultType><remoteFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>oracle.fabric.common.FabricInvocationException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target</summary></part><part name="code"><code>null</code></part><part name="detail"><detail>unable to find valid certification path to requested target</detail></part></remoteFault></bpelFault></fault><faultType>
<message>0</message></faultType></messages>
In de server.out a java exception is found shortly after invoking the service reporting that a valid certification path cannot be found
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The received certificate chain is as expected, a root CA, intermediate and server certificate. (also extracted from the server.out)
The cause seems to be that weblogic is not using the configured custom truststore but the default Java truststore. (yes, nodemanager, admin and managed server have been restarted) This explains why the certification path is not valid, but have currently not a clue how to resolve this.
<Jun 23, 2016 10:15:27 PM CEST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 12.2.1.0.0 Tue Oct 6 10:05:47 PDT 2015 1721936>
trustStore is: /usr/java/jdk1.8.0_92/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Any suggestion, hint or solution is welcome!
-- Update 1 --
Found the following in the document "Fusion Middleware Securing Oracle WebLogic Server"
How WebLogic Server Locates Trust
WebLogic Server uses the following algorithm when it loads its trusted CA certificates:
If the keystore is specified by the -Dweblogic.security.SSL.trustedCAkeystore command-line argument, load the trusted CA certificates from that keystore.
Else if the keystore is specified in the configuration file (config.xml), load trusted CA certificates from the specified keystore. If the server is configured with DemoTrust, trusted CA certificates will be loaded from the WL_HOME\server\lib\DemoTrust.jks and the JDK cacerts keystores.
Else if the trusted CA file is specified in the configuration file
(config.xml), load trusted CA certificates from that file (this is
only for compatibility with 6.x SSL configurations).
Else load trusted CA certificates from WL_HOME\server\lib\cacerts
keystore.
The argument -Dweblogic.security.SSL.trustedCAkeystore is not used and therefore should load the trusted CA certificates from the custom truststore.
-- update 2 --
For the outbound web service bindings, Oracle SOA Suite uses JRF HttpClient and, therefore, the Sun JDK libraries for SSL. Therefore the -Djavax.net.ssl.trustStore=your_truststore_location has to be added to the JAVA_OPTIONS in the startweblogic.sh
After adding the truststore property to the JAVA_PROPERIES the following is logged in the server.out file..
soa_server1.out:/u01/data/domains/soa12c/bin/setDomainEnv.sh: line 384: -Djava.net.ssl.trustStore=/u01/data/keystores/truststore.jks: No such file or directory
File exist, domain user has file access to the jks file.
It is not working because whatever you've put is overwritten by Demo Trust. If you got to manager server bin path and open setDomainEnv and search for Demo you'll see Demo trust JKS. Remove it and then restart your SOA server.
One quote on the wrong position.....
I initally alreadt removed the java property -Djava.net.ssl.trustStore from the JAVA_PROPERTIES in the setDomainEnv.sh. And placed a new property -Djava.net.ssl.trustStore for he truststore. But placed it -outside- the double quotes enclosing the contents of JAVA_PROPERTIES. That explains why it defaulted back to cacerts ..
I am currently using Jetty for http and want to open up https connectors now. I saw there is a keystore file that comes with Jetty installation under etc directory in jetty home. My understanding is that SSL certificates and keystores are something that users will create/generate and use for their servers.
Could somebody please hemp me understand -- What does this default keystore file that comes with Jetty installation contain and why will somebody ever need this?
Thanks!
The keystore file that Jetty comes with is a demonstration Keystore that is used by the demo webapps.
You are meant to create your own keystore from your own SSL certificates.
As for how to do this, see the documentation from the SSL CA (Certificate Authority) you purchased your certificates from, or from the Jetty documentation.
I followed the instructions given on this page to import the server certificate.
When I use keytool -list, I can see that the certificate is actually in the keystore. If I try to import the .crt file, keytool warns me that the keystore already contains the certificate.
Then I updated wrapper.conf with the two ssl options. I can see them on the command line of the Nexus process after a restart.
But when I try to add a proxy repo for the remote server, I always get sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
What did I miss?
You have to import the custom CA certificate into the 'trustStore' and not into the 'keyStore'.
The procedure for creating a 'trustStore' is the same as the one for the 'keyStore'.
Once you have your *.jks file then link it using the following system properties:
javax.net.ssl.trustStore=<file>
javax.net.ssl.trustStorePassword=<password>
Error message means the JVM cannot properly authenticate the remote server's SSL cert. Very common if the remote server is using a self-signed cert instead of one signed by an official certificate authority (like verisign).
Your message is confusing. You've enabled SSL on your Nexus instance, however you talk about a proxy repo implying the problem SSL cert might be on another server.