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.
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 got a secure cluster NIFI with 3 nodes, configured with truststore.jks and keystore.jks
In my invokeHTTP, i've set "StandardSSLContextService" with keystore and trustore for https.
invokeHTTP works when i'm trying https://nifi:9443/nifi-api/controller/config
but not works when i'm trying "https://auth_server/oauth/access_token"
So when I'm trying use invokeHTTP to get token but it failed with this error :
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
thanks for helps
The StandardSSLContextService can be configured with a truststore, which is a Java KeyStore object which contains a collection of TrustedCertEntry objects -- each of which holds the public key and certificate information of a trusted entity. When Apache NiFi attempts to contact some other endpoint or service over HTTPS, it evaluates the received certificate identifying the service and attempts to validate that certificate. If the endpoint certificate is not directly contained in the truststore, it checks to see which certificate signed the leaf cert, and validate that one. This process continues up the certificate chain until either a cert is found that is trusted, or none are.
The error message you are receiving is stating that none of the certificates in the chain could be verified. As daggett pointed out, you could manually import the certificate of the service you want to validate into a custom truststore. If this is a service available on the public internet and signed by a generally trusted certificate authority (CA), you can also point your StandardSSLContextService to the default list provided by Java. The cacerts truststore is included automatically, and has a similar trusted entry list to modern browsers. It is found in $JAVA_HOME/jre/lib/security/cacerts. You can determine the value of $JAVA_HOME for your OS and Java version.
Truststore filename: /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts (example)
Truststore password: changeit (default value)
Truststore type: JKS
We are developing an application using tomcat and jersey.
Within this webapplication we need to connect to a https Website with a valid, not expired certificate.
If I do connect to this website locally via my chrome browser, everything works fine!
Unfortunately the tomcat server with our webapp throws an exception. We are using the Apache HttpClient (4.0) to connect to the https site:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The server certificate is absolutely valid and from thawte.
Three different online tools validated the certificate successfully.
Openssl has an issue, too and showing me three certificates but throwing a simple error:
Verify return code: 20 (unable to get local issuer certificate)
The problem with openssl seems to be that it uses the wrong path /usr/lib/sslinstead of /etc/ssl/certs. If I use the CApath argument pointing to the proper path, openssl works fine so may this be an issue with the httpClient?
So our code for the default client is quite simple:
client = new DefaultHttpClient();
response = client.execute(url); //this throws the exception
EntityUtils.consume(response.getEntity());
It's not an option to allow any certificates by implementing a custom TrustedManager!
Futher I read, that some CA's are not part of the JDK/JRE and so it's certificates should be imported manually into the keystore or use a custom one, but thawte is a well known CA and shouldn't it work on default?
EDIT
I did set the javax.debug properties in catalina.sh so that I have further information about the problem:
http-bio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: basic constraints check failed:
pathLenConstraint violated - this cert must be the last cert in the certification path
I would appreciate any help!
Thanks in advance!
Okay, I got it working!
Although thawte is a well known CA it seems that Java SSL did have some problems with it.
After downloading the ssl Certificate via openssl:
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
and saving it into an pem file, I did the manual import into the java keystore:
keytool -import -alias myAlias -file theCert.pem -keystore lib/security/cacerts
I have no idea why java ssl was not able to validate the thawte certificate properly.
Listing the keystore showed me, that there are 7 thawte trusted certificates in the standard keystore but bizarrely it did not work until I manually imported the pem file
I am trying to understand your setup. You have a SSL certificate (issued by Thwate), installed in tomcat and you can access your site just fine over SSL using say IE or Firefox or Chrome.
But when you try to access it using HttpClient, you receive the above error ?
Is that correct ?
The error clearly indicates that your client does not trust the CA. But if the cert is signed by Thwate (and is installed correctly and is acessible via IE/Firefox etc), then it should work fine.
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?