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
Related
I'm sitting behind a coorporate proxy that has its own certificate. E.g. when I want my Java runtime to be able to communicate with the outer world I need to import my "coorporate certificate" to the Java truststore e.g. with keytool -import -keystore %JAVA_HOME%/jre/lib/security/cacerts -trustcacerts -file coorp-cert.crt
How do I import this certificate to Apache Karaf (4.3.0)?
Background:
I cannot install features into Karaf. E.g. karaf#root()> feature:repo-add ecf results in the error Error executing command: Connection refused: connect : [...]. The proxy is configured correctly (tested with maven:summary which displays valid "HTTP Proxies" values). So I suspect the missing proxy certificate is causing this problem.
Okay, although the commands http:proxy-list and maven:summary displayed the correct proxy settings, I fixed the problem by appending -Dhttps.proxyHost=<proxy url> -Dhttps.proxyPort=<proxy port> in the line starting with set DEFAULT_JAVA_OPTS in the $KARAF_HOME/bin/karaf.bat file. Alternatively one can probably set the JAVA_OPTS or EXTRA_JAVA_OPTS variables before starting karaf (haven't tested the latter, though).
The certificate apparently wasn't the problem.
I want to install bamboo agent on my working computer. I have downloaded the jar file and try to run it with following syntax
java -jar atlassian-bamboo-agent-installer-5.7.0.jar https://bamboo.xxxxx.org/agentServer/
I got error javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
The source of this error is clear to me - we have a self-signed SSL sertificate. I tried to run with following parameters
java -Dbamboo.agent.ignoreServerCertName=true -jar atlassian-bamboo-agent-installer-5.7.0.jar https://bamboo.xxxxx.org/agentServer/
but it does not work as well.
I tried to add the certificate using this link Java keytool easy way to add server cert from url/port
The sertificate seems to be installed, but it does not help. I still have the following error.
Do you know how can I fix it?
The problem was that bamboo did not obtained (for some reason) the keystorage created by keytool.
I needed to manually set the keystore in the bamboo configuration. In config/wrapper.conf you need to add following lines
wrapper.java.additional.3=-Djavax.net.ssl.keyStore=/#MODIFY_ME_TO_MY_HOME#/bamboo-agent-home/keystores/client.ks
wrapper.java.additional.4=-Djavax.net.ssl.keyStorePassword=#MY_AWESOME_PASSWORD#
wrapper.java.additional.5=-Djavax.net.ssl.trustStore=/#MODIFY_ME_TO_MY_HOME#/bamboo-agent-home/keystores/client.ts
This can be caused if you are running Bamboo behind Apache with SSL, if your default SSL VirtualHost is not returning the same SSLCertificate as your Bamboo VirtualHost. We had a similar problem, because I didn't know /etc/httpd/conf.d/ssl.conf created a VirtualHost.
First, I had installed jdk 1.6.0_43 and oracle weblogic 12.1.1, I was successfully able to deploy my application.
I then upgraded both my jdk (1.7.0_60) and weblogic (12.1.2), but was unable to deploy my application.
Now, I downgraded my weblogic (12.1.1) but retained my jdk 1.7.0_60, but i was still not able to deploy my application successfully.
In both the failure cases, I got the same error with the following message. Is there something with respect to java 7 I should be aware of? I tried searching for this a lot, but in vain..
[exec] javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://localhost:9991: Destination unreachable; nested exception is:
[exec] java.net.ConnectException: Connection refused: connect; No available router to destination]
No available router to destination -- Means you do not have a service running to listen on localhost:9991
Go to admin console, check the servers which should be listening on 9991 is up and running.
I am sure it is not running.
a few possibilities
Not listening - check with netstat
No tunneling - check Summary of Servers -> Configure server (admin) -> Protocols tab -> HTTP sub tab-> Enable Tunneling
JDeveloper does not trust the SSL certificate - check root CA e.g.
$ cd /oracle/Middleware-12.2.1.2/oracle_common
$ jdk/bin/keytool -import -v -file ca.crt -storepass changeit -keystore jdk/jre/lib/security/cacerts -alias MyCA
oracle's blog points that you have to enable tunneling:
access the administration console, click servers-> server you want to
reach-> protocols -> http -> enable Tunneling.
Follow these steps (Must be done on Admin only):
Login to Weblogic Console
Click Lock and Edit
Go to Servers
Go to Admin
Go to protocols
Go to HTTP
Scroll down and click on Enable Tunneling
Save
Activate (No restart needed)
I had a similar issue with my Weblogic server while building with maven
If you're using maven, make sure in your maven settings.xml file, the value for: <weblogic.admin.url></weblogic.admin.url> is the same what you have for listen-address></listen-address> your weblogic config.xml
My problem was that my settings.xml had my local IP address where as weblogic config.xml had localhost.
I had the similar problem in WebLogic Server Version: 12.2.1.3.0 and it was resolved by changing the SSL port. On the same server, Admin server and managed server had similar ports for the SSL even though both the ports were disabled yet there was conflict. After changing the ssl port number i was able to solve the problem.
Go to Weblogic Console
Click on the managed server
Under configuration -> General enable ssl and ensure the port mentioned is unique and is not being used by AdminServer or any of the managed servers.
I keep having some weird problems. The main one is that I keep getting the following error when trying to add a WSDL to a new project:
Error loading [https://.../token?wsdl]: java.lang.Exception: Failed to load url; https://.../token?wsdl, 0 -
Here's the message recorded in the error.log file:
java.lang.Exception: Failed to load url; https://.../token?wsdl, 0 -
at com.eviware.soapui.impl.wsdl.support.wsdl.UrlWsdlLoader.load(UrlWsdlLoader.java:184)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlLoader.loadXmlObject(WsdlLoader.java:121)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:535)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:524)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionCache.update(AbstractDefinitionCache.java:97)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext$Loader.construct(AbstractDefinitionContext.java:226)
at com.eviware.soapui.support.swing.SwingWorkerDelegator.construct(SwingWorkerDelegator.java:46)
at com.eviware.soapui.support.swing.SwingWorker$2.run(SwingWorker.java:149)
at java.lang.Thread.run(Unknown Source)
I verified that the application at that URL is up and running, and I can get to the WSDL from a web browser, but I keep getting this error message no matter what. I am using SoapUI 4.5.0 (32-bit) on a Windows 7 box. I've also tried the 64-bit version with the same results. It happens whether I am on VPN or not.
Do you know why I might be getting this error?
I have had the same problem. I resolved it by disabling the proxy in the SoapUI preferences.
(source : http://www.eviware.com/forum/viewtopic.php?f=13&t=12460)
In my case the server were the service was installed was configured only for TLS. SSL was not allowed. So you have to update SoapUI vmoptions file by adding the server TLS version
-Dsoapui.https.protocols=TLSv1.2
You can find vmoptions file under SoapUI installation folder:
C:\Program Files (x86)\SmartBear\SoapUI-5.0.0\bin\soapUI-5.0.0.vmoptions
I have had similar problems and worked around them by saving the WSDL locally. Don't forget to save any XSD files as well. You may need to edit the WSDL to specify an appropriate location for XSDs.
I got this error when trying to load a WebService implemented in MS Dynamics AX. Because I was connecting via VPN to my network, something went wrong with IPv6 settings. After Googling, I found the solution here: http://support.microsoft.com/kb/929852
In my case the
Error loading [https://.../token?wsdl]: java.lang.Exception: Failed to load url; https://.../token?wsdl, 0
was caused by fake certificate.
If you get the following in browser
"There is a problem with this website’s security certificate."
this is the case.
The resolution was to import a certificate to
C:\Program Files (x86)\SmartBear\SoapUI-5.0.0\jre\lib\security\cacerts
Which is default java used by SOAPUI
This could be a problem with IPV6 address SOAP UI picking. Adding the following JVM option fixed it for me:
-Djava.net.preferIPv4Stack=true
I added it here:
C:\Program Files\SmartBear\soapUI-4.5.2\bin\soapUI-4.5.2.vmoptions
Inside the wsdl file look for the import element, which looks like this :
`<import namespace="nameSpaceValue" location="Users/myname/.../targetxsdName.xsd"/>`
Change the location attribute in the above element to the location of your xsd files stored locally, and it should work.
The following solution helped me:
-Djsse.enableSNIExtension=false
In SoapUI-5.3.0.vmoptions.
This error is due to an erroneous schemaLocation in the WSDL file.
Indicate the correct location (either path on the disk or xsd url) of the xsd file in the wsdl file
exp
<xsd:import namespace="http://xyz:8080/" schemaLocation="http://172.17.16.53:9080/auth/authorizationBS?xsd=1"></xsd:import>
I had this issue when trying to use a SOCKS proxy. It appears that SoapUI does not support SOCKS proxys. I am using the Boomerang Chrome app instead.
I had this error and in my case, the problem was that I was using "localhost" in the URL.
I resolved that changing the localhost word for the respective IP, (Windows + R -> cmd -> ipconfig) then read the IP and write it to the URL replacing the "localhost" word
Close and reopen soapui. Probably is a bug of the application
Update SoapUI version to SoapUI 5.5.0. This error causes when I tried to load wsdl, because of old SoapUI version
If you are running your Web Application with the default port of 8080, please try to change the port to some other value and run your application again and trigger again your SOAPUI request. As you might have history projects in your SOAP UI workspace with port number 8080, might create issues.
My solution was to modify the java.security file:
\SoapUI-5.3.0\jre\lib\security\java.security
Comment code syntax:
#jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
For java version above 1.8,
Use below command to setup soapUI jar
java -jar --add-modules java.xml.bind --add-modules java.xml.ws <path for jar file+jar file name.jar>
We have signed a JAR file using a certificate generated by MS Active Directory Certificate Services. However, when accessing it via Java Web Start we are getting the prompt that the digital signature cannot be verified even though we've installed the root CA into the certificate store on the client machine.
Now trying to look at the root CA on the client machine, using "keytool -list", I'm seeing an exception (invalid URI:file://\my_msadcs_server\path\to\CRL.crl). So now I'm not sure exactly what is going wrong.
Anyone have a suggestion or sample Java code on how I can test the downloaded JAR file's signature on the client machine in an attempt to figure out exactly why JWS is complaining? It could be that the root CA certificate has a problem (and I will chase down that avenue when my AD admin gets in) but I'd like to rule out other possibilities first. Currently the only thing I have to go on is the exception from "keytool -list", but keytool had no issues importing the root CA certificate in the first place.
Thanks in advance!,
mG.
I use jarsigner with the -verify, -verbose and -certs options. You may have to specify your -keystore, too.
I think the invalid URI message is a clue. Java file URI takes the following form: file://host/path