Unable to connect mule Anypoint Connectors Update Site - mule

I'm trying to download object store.
I'm getting below error while connecting to Anypoint Connectors Update Site - https://repository.mulesoft.org/connectors/releases/3.5.0
Unable to read repository at https://repository.mulesoft.org/connectors/releases/3.5.0/content.xml.
Unable to read repository at https://repository.mulesoft.org/connectors/releases/3.5.0/content.xml.
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It seems you are facing some ssl certificate issues, this usually occurs when your JVM truststore contains self-signed certificates (i.e. certificates not signed by a CA).
This case occurs when Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to that application if it can trust it. The way trust is handled in the Java world is that you have a keystore (typically $JAVA_HOME/lib/security/cacerts), also known as the truststore. This contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CAs or public certificates that exist within that keystore.
But before jumping to conclusion do check Case 1 and 2
Case 1 : Check if the link is not blocked by your firewall
Do refer the Mulesoft Doc
Case 2 : Simply update your java (this is easy way)
Case 3 : Download Certificate manually and add in Java's truststore
Refer this link to know how to download certificate manually and this link to add the certificate to the truststore (you will need OpenSSL toolkit to transform the certificate to required format, it is described in the the mentioned link), and in case you are not familiar with different extension related to SSl certificate go check out this SO answer

Related

How to consume an API that use a self signed SSL?

is there any one who can provide me with the way of consuming an API that use a self signed SSL in xamarin android.
An Exception thrown says:
Javax.Net.Ssl.HandshakeException:
'java.security.cert.CertPathValidatorException: Trust anchor for certification path not found'.
enter image description here
You can try to check whether SSL Certificate is correctly configured with the Certificate in your web.
We have to add the intermediate certificates in generating the .pem file.
You can go through this thread to install the intermediate certificate in your server:
Trust Anchor not found for Android SSL Connection
And there is a similar thread about this, you can check it here:Trust anchor for certification path not found [ Xamarin.Forms ] .

InstallCert.java crashes server before certificates are retrieved

I have a server running on Dropwizard (i.e. running Jetty for its web server). I'm trying to set up SSL for it.
I have a certificate signed by a CA (specifically Comodo, through Namecheap). I installed the root and intermediate certificates, then installed my own certificate (using the instructions on Comodo's support. Nonetheless, when I attempt to connect to my server for the first time (it boots fine), I get an error: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (Of course the stack trace is much longer, but that's the root cause.)
I've tried searching this error, and consistently people say it should only happen for self-signed certificates, which mine is not. Nonetheless, I tried downloading the InstallCert.java program that seems to have originated from a (now removed) article on the Sun blog. Specifically I got the degree from this page.
After several (failed) attempts to get it to work by command line (that's a discussion for another time), I eventually got it to run properly. Now the output I get from the program is:
Loading KeyStore C:\Program Files\Java\jdk1.8.0_05\jre\lib\security\cacerts...
Opening connection to localhost:8443...
Starting SSL handshake...
Exception in thread "main" java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
at com.aw.ad.util.InstallCert.main(InstallCert.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Process finished with exit code 1
Meanwhile, if I open the window with my website, it once more delivers the unable to find valid certification path to requested target error and crashed (hence leading to the timeout). In essence, what it seems to me is that InstallCerts (which should fix my SSL problems) is crashing my server due to the SSL issues.
If I try using something like openssl s_client -connect localhost:8443 -showcerts (which was a recommendation I saw somewhere, save the results of that to a .pem file and install that), the same thing happens.
Is there a solution this problem? Am I missing something obvious here?
You might be missing the whole chain of certificates from Comodo root CA to your site's certificate. Examine the keystore that you configured in Dropwizard and see if you have them all. The simplest way is to look for the issuer of your certificate, you need to have the certificate with the same subject, next look for the issuer of that certificate and so forth. To be sure try to chain authority key identifier certificate extension of your certificate with the key fingerprint (key identifier) of the issuer, and the issuer's issuer. If you provide
keytool -list -keystore <your keystore> -rfc
I might be able to help you more...
Added later:
I've managed to reproduce your problem exactly. TL;DR; add:
validateCerts: true
trustStorePath: lyonesgamer.com.keystore
enableCRLDP: true
I created a keystore containing the chain (single entry, 3 certificates, ca, subordinate ca and end entity certificate) and another keystore containing only the two ca certificates as trusted entries. Then I configured keyStorePath, keyStorePassword, trustStorePath and validateCerts: true.
This resulted in:
java.security.cert.CertificateException: Unable to validate certificate: unable to find valid certification path to requested target
After adding -Djava.security.debug=certpath I noticed that revocation checking was failing, and that this in fact was the root cause of certificate chain failure:
certpath: SunCertPathBuilder.depthFirstSearchForward(): validation failed:
java.security.cert.CertPathValidatorException: Could not determine revocation status
Then I remembered that if you do not enable CRL Distribution Point extension usage for the CertPath API you need to specify the CRL yourself. Fortunately Dropwizard has an option to enable the CRLDP: enableCRLDP: true. With it enabled application successfully starts.
Alternatively you could keep the CRL in a file and point crlPath to it.
After all this time, I'd been chasing a rabbit hole. It turned out the problem was that I (rather naively) was testing this on my own computer. Dropwizard's validation saw an error, because the certificate was only valid for my domain, which my personal computer is not a member of. Hence it crashed because it couldn't validate.
I discovered this by turning validateCerts off in my Dropwizard config file (I had thought I'd turned it off already, but apparently not). Dropwizard booted fine and allowed me to connect. When I did, then Firefox gave me an Untrusted Connection error, and clicking on Details gave me the much more useful information:
localhost:8443 uses an invalid security certificate.
The certificate is only valid for the following names: lyonesgamer.com, www.lyonesgamer.com
(Error code: ssl_error_bad_cert_domain)
Thank you, Zoran, very much for trying to help. I'm afraid much of it was in vain.

IBM Worklight 5.0.6: Direct Update - SSLHandshakeException

My app connects to Worklight server through HTTPS through self-signed certificate. The app can be launched successfully.
However, when there is direct update which started downloading file from Worklight server, it is failed and I can see that there are error message regarding certification path not found.
May I know if the SSLHandshakeException and direct update error are correlated?
Thanks!
(Environment: Worklight 5.0.6.1, WAS ND 8.5, Testing Device: HTC One)
10-31 21:24:50.897: W/System.err(28746): Catch exception while startHandshake: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
10-31 21:24:50.897: W/System.err(28746): return an invalid session with invalid cipher suite of SSL_NULL_WITH_NULL_NULL
10-31 21:24:50.927: E/WLDroidGap(28746): Failed downloading application update file.
Yes, the use of direct update and the SSL handshake errors are related. Android doesn't allow you to work with self-signed certificates (unless you somehow bypass SSL). Because you can't install a self-signed cert into Android's truststore, the Android client can't establish trust for the server's self signed certificate.
You probably have the following flag specified in your Android manifest file:
android:debuggable="true"
This flag disables SSL validation when going thru the hybrid channels and probably the reason why you don't see the SSL errors earlier. Direct update is handled at a different level, where this flag does not apply, and therefore SSL validation does occur.
You should use self-signed CA certificates instead for dev/test purposes. See the following answer on how to generate a self-signed CA:
https://stackoverflow.com/a/19841469/2494287
Direct update will not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.

Issuer details are not valid. Issuer details should be registered in advance

I am trying to run a test of the SAML2 SSO using WSO2 Identity Server 4.0.0 M7 but am not successful.
I tried to use the 3.2.3 binary but ran into the bug about long hostnames and the identity.xml file (http://stackoverflow.com/questions/9600392/unable-to-configure-wso2-identity-server-for-openid).
These are the examples I'm using:
http://sureshatt.blogspot.com/2012/08/saml20-sso-with-wso2-identity-server.html
http://wso2.org/library/articles/2010/07/saml2-web-browser-based-sso-wso2-identity-server
I've stood up a new Tomcat7 server and configured it for HTTPS, which works cleanly in the browser. The certs are signed by our trusted enterprise CA and both the private key and chain certs are installed.
Same for the WSO2-IS host which has a new wso2carbon.jks with the private key signed by the same CA. I've exported the host cert from wso2carbon.jks and imported same into the client-truststore.jks. The trusted CA-signed certs are also in client-truststore.jks (at this point just to be sure). They are also in wso2carbon.jks (used to trust the CA reply).
I've changed the HostName and MgtHostName in carbon.xml to match the CN in the private key; the Carbon console comes up cleanly with no SSL issues and I can log in using the 'admin' user with no problem. From there I've updated the SSO configuration using the above example links as guides. That works with no errors.
When I go to each site (e.g., saml2.demo, avis.com, etc.) they redirect perfectly to IS to authenticate. However when I log in I get the error in the log "Issuer details are not valid. Issuer details should be registered in advance". And then I'm stuck.
What have I missed?
Have you done the 5th step of the topic 2 Configuring the WSO2 Identity Server ? Please check the value you've registered as the Issuer is as same as the one that comes in the SAML Authentication Request message.

Unable to load web app

Unable to load web application and console says the following
InstallationHandlers.isRegistered() failed, reason:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
what does it means? Any Idea ?
Thanks,
Pramod
Check your SSL settings. Try to turn off SSL and see if it helps.
And, as error msg says, check all paths to keystores and all certificate aliases.
I don't use glassfish - I just look at error message. PKIX is format of file, that contains certificates. All certificates, depending of CA (certificate authority), belong to different paths. Example: certificate from Thawte belongs to Thawte certficiate paths, cert from Verisign belong to Verisign path. So there is something wrong with certificate you use: it does not belong to any registered path, I think. One of the most popular ways to use certificates is SSL, so I presume this is your case. SSL settings should be somewhere in glassfish - google it. Or, maybe, you can make your application use unencrypted connections.