Server: Windows Server 2012
Cold Fusion: 9,0,1,274733
Update-Level: hf901-00011.jar
Running on java version: 1.7.0_79
Java home points to the right path.
All certificates (for live and sandbox) are imported into the keystore of this JDK 1.7.0_79. I've tested it and renaming the cacerts file results in an error when connecting to the live API.
Testing the cacerts file using the keytool shows that the apropriate certificates are properly imported.
A little order app provides payment using PayPal.
First step is a connection to PayPal using the method "setExpressCheckout".
The connection to the live API using NVP at URL https://api-3t.paypal.com/nvp works and delivers the token URL-string.
The connection to the sandbox API using NVP at URL https://api-3t.sandbox.paypal.com/nvp fails with the error response:
I/O Exception: peer not authenticated
Connection Failure
Unable to determine MIME type of file.
Connection Failure. Status code unavailable.
Calling the URL https://api-3t.sandbox.paypal.com/nvp from the server works.
Test 1
imported the sandbox certificate for api-3t.sandbox.paypal.com
restart CF service
connection test failed with the same error
Test 2
renamed the cacerts file to cacerts.bak
copied the cacerts file from jre1.8.0_31\lib\security to the 1.7.0_79\lib\security
there is no specific PayPal cert in the cacerts file
restart the CF service
connection to live API works
connection to sandbox api fails with the same error
The weird thing is that the connection to the live api works without importing the specific certificate into the keystore when using the 1.8xx cacerts file.
I can't figure out why the connection to the sandbox fails. Maybe I can get new hints here?
If there are more informations needed please let me know. Thank you in advance.
Problem solved!
Scott Jibben (see his comment above) mentioned that the PayPal sandbox may already decline TLS1 connections in order to the upcoming change to do so in the PayPal live API.
This is absolutely right. But while in CF11 this isn't a problem because CF11 and its JRE are already using TLSv1.2, CF8-10 are using the default protocol of their JRE.
If not, one can force CF to use TLSv1.2 with the JVM argument
-Dhttps.protocols=TLSv1.2
Short:
CF8-10 are using TLSv1 while running with JDK1.70_79 and below no matter what the JVM startup argument -Dhttps.protocols was set to.
This is because the default protocol of these Java versions is TLSv1 and CF8-10 are simply ignoring the JVM startup argument -Dhttps.protocols and always use the JDK's default protocol.
This has changed with CF11 therefore it works fine with it.
Read detailed informations in a post from Wil Genovese at:
https://www.trunkful.com/index.cfm/2014/12/8/Preventing-SSLv3-Fallback-in-ColdFusion
What I did
I've installed the JDK1.8.0_144 and set up Cold Fusion 9 to use this one. Since then the connection to the PayPal sandbox API at api-3t.sandbox.paypal.com works pretty well.
Hope this may help others with this old and by now a little odd CF9.
Related
Trying to sign an OutlookAdd-In with a GoDaddy certificate using http://tsa.starfieldtech.com as the Timestamp server, but was getting "signing parameter is incorrect". Now getting "An error occurred while signing: Timestamp URL server name or address could not be resolved." I successfully utilized http://timestamp.comodoca.com/authenticode in order to get it out to users but am not completely comfortable using a new URL. Are others experiencing this issue?
Thanks!
Here's my 2¢:
As of a couple of days ago, GoDaddy withdrew from the code signing certificate (CSC) business. GoDaddy have told me they will honor my certificate till its expiry, which is 2023.
GoDaddy tech support tell me that starfieldtech.com, GoDaddy's recommended TSA (Time Stamp Authority) server, no longer recognizes GoDaddy CSCs. Using MS SDK signtool.exe, I have tried the following alternatives, all of which fail with the error "The specified timestamp server either could not be reached or returned an invalid response.":
http://tsa.starfieldtech.com/
http://timestamp.digicert.com?alg=sha1
http://timestamp.globalsign.com/scripts/timstamp.dll
http://www.startssl.com/timestamp
http://rfc3161timestamp.globalsign.com/advanced
https://timestamp.geotrust.com/tsa
http://tsa.startssl.com/rfc3161
http://www.trustcenter.de/codesigning/timestamp
http://freetsa.org/tsr/
http://freetsa.org
https://freetsa.org
The only one that still works is:
http://timestamp.comodoca.com/authenticode
I'm skeptical that TSA server is sufficient, I think the problem goes deeper than that.
I have also reviewed https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710.
Does anyone know of other reputable TSAs that work?
I'd rather not have to prematurely replace my expensive CSC.
It's dead.
Browser shows Server not found.
Name resolution fails:
nslookup tsa.starfieldtech.com
...
can't find tsa.starfieldtech.com.: Non-existent domain
I have owncloud version 9.1.8 running on a synology. Now I installed onlyoffice on a local server with a self signed certificat. It is important to know, that the onlyoffice server is running locally in a network. So I cannot access the server like e.g. with lets encrypt, because I only have a local server name and not a public server name. Lets Encrypt therefore cannot verify the server. However if I want (and if you have a solution doing that), I can access the internet using the server.
Now i have the problem, that owncloud delivers me the following error message
"Error while downloading the document file to be converted."
when I want to save the url in the onlyoffice configuration in owncloud. I guess the problem is, that I am using a self signed certificat. Do you know what I can do? Google does not really help me.
"Error while downloading the document file to be converted."
means that DocumentServer cannot validate your storage's self-signed certificate (OC in your case)
There are 2 possible workarounds:
1) Change "rejectUnauthorized" to false in the /etc/onlyoffice/documentserver/default.json config file
2) Change the default Node.js CAstore:
Edit the files:
/etc/supervisor/conf.d/onlyoffice-documentserver-converter.conf
/etc/supervisor/conf.d/onlyoffice-documentserver-docservice.conf
Add a flag --use-openssl-ca to the parameters in this line
Then you need to add your certificate to the the default CA store and restart ONLYOFFICE services:
supervisorctl restart all
my website is www.a1mcganns.co.uk
I am having issues with customers completing payment when using PayPal.
They get this error message
PayPal response:
->
Making new connection to 'api-3t.paypal.com/nvp'
Connect with CURL method successful
Sending this params:
METHOD=SetExpressCheckout&VERSION=106&PWD=L2JP7EMP7JR32JCP&USER=sales_api1.a1mcganns.co.uk&SIGNATURE=AENSDlLTRY8C54MMOG29Y0inxhFWAgY-7uEg9VqBu-bS11n1QZx2H3Nv&CANCELURL=http%3A%2F%2Fwww.a1mcganns.co.uk%2Fgb%2Forder%3Fpaypal_ec_canceled%3D1%26&RETURNURL=http%3A%2F%2Fwww.a1mcganns.co.uk%2Fmodules%2Fpaypal%2Fexpress_checkout%2Fpayment.php&NOSHIPPING=1&BUTTONSOURCE=PRESTASHOP_EC&L_PAYMENTREQUEST_0_NUMBER0=1733&L_PAYMENTREQUEST_0_NAME0=Cycliq+Fly+12+Front+1080p+Camera+and+400+lumen+Bike+Light+%28Includes+16GB+SD+Card%29&L_PAYMENTREQUEST_0_DESC0=Inludes+16GB+SD+Card...&L_PAYMENTREQUEST_0_AMT0=229.99&L_PAYMENTREQUEST_0_QTY0=1&PAYMENTREQUEST_0_PAYMENTACTION=Sale&PAYMENTREQUEST_0_CURRENCYCODE=GBP&PAYMENTREQUEST_0_SHIPPINGAMT=0.00&PAYMENTREQUEST_0_ITEMAMT=229.99&PAYMENTREQUEST_0_AMT=229.99&ADDROVERRIDE=1&EMAIL=phil%40wilkinson3.fsworld.co.uk&PAYMENTREQUEST_0_SHIPTONAME=p+Wilkinson&PAYMENTREQUEST_0_SHIPTOPHONENUM=%2B447595914321&PAYMENTREQUEST_0_SHIPTOSTREET=63&PAYMENTREQUEST_0_SHIPTOSTREET2=Northampton+Lane+North&PAYMENTREQUEST_0_SHIPTOCITY=Northampton&PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE=GB&PAYMENTREQUEST_0_SHIPTOZIP=NN3+7QY&SOLUTIONTYPE=Sole&LANDINGPAGE=Login&USER=sales_api1.a1mcganns.co.uk&PWD=L2JP7EMP7JR32JCP&SIGNATURE=AENSDlLTRY8C54MMOG29Y0inxhFWAgY-7uEg9VqBu-bS11n1QZx2H3Nv
Send with CURL method failed ! Error: Couldn't resolve host 'api-3t.paypal.com'
Connect failed with fsockopen method
I am hoping someone can point me in the right direction to fix the problem
Many thanks
Regards
Phil
Check the curl error to see exactly what's happening. My guess is that you'll get something along the lines of "ssl handshake failure".
If that's the case you need to review this post about POODLE.
The problem basically comes down to the server software stack being out of date. Specifically, from the POODLE post...
As of 01.19.2016 PayPal now supports only TLS 1.2 on the sandbox (and in June the same will apply to production systems).
If you want to use TLS 1.2 you’ll need to upgrade to OpenSSL 1.0.1 as a minimum, and then you’ll be able to set CURLOPT_SSLVERSION to 6 (TLS 1.2).
If you want TLS 1.2 to be used automatically during SSL requests, you’ll also need to upgrade to PHP 5.5.19+ (this is the ideal solution but many projects are still on older PHP versions).
I set up an application with the Intuit Customer Account Data API and am running a Rails app using Aggcat gem (https://github.com/cloocher/aggcat). I had to replace my certificate and followed the instructions for OpenSSL found here. Under My Apps I uploaded the new public certificate and changed the settings on Aggcat to use the new private key file generated with it.
I can run client.scope(1) but when I try to run anything else (such as client.institutions) I get a bad request error (400). Any ideas what the problem could be? I've tried re-generating the certificate multiple times and no luck.
According IPP's site,
400 - Bad Request represents - If the URL or variables are not in the correct format this error will display.
Ref - https://developer.intuit.com/docs/0020_customeraccountdata/customer_account_data_api/0700_error_codes
I've not tried CAD calls using ruby but I use the sample JAVA app(IPP).
You can run the sample java app ( by configuring the devkit logger in debug mode) and capture the raw request/response and URL(and parameters) and compare the same which you're getting in your ruby example. That might help you to debug these issues.
Otherwise, you can also try the other two ruby examples which are available here-
https://developer.intuit.com/docs/0020_customeraccountdata/devkits
https://github.com/cheqbook/intuit_ids_aggcat
https://github.com/rewardsummit/intuit_ids_aggcat
Thanks
When trying to hit an environment with improperly configured SSL certificates, I get the following error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:562)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
at dispatch.BlockingHttp$class.dispatch$BlockingHttp$$execute(Http.scala:45)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at scala.Option.getOrElse(Option.scala:108)
at dispatch.BlockingHttp$$anonfun$execute$1.apply(Http.scala:58)
at dispatch.Http.pack(Http.scala:25)
at dispatch.BlockingHttp$class.execute(Http.scala:53)
at dispatch.Http.execute(Http.scala:21)
at dispatch.HttpExecutor$class.x(executor.scala:36)
at dispatch.Http.x(Http.scala:21)
at dispatch.HttpExecutor$class.when(executor.scala:50)
at dispatch.Http.when(Http.scala:21)
at dispatch.HttpExecutor$class.apply(executor.scala:60)
at dispatch.Http.apply(Http.scala:21)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.tdsGet(UsersBDTest.scala:130)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.setup(UsersBDTest.scala:40)
I would like to ignore the certificates entirely.
Update: I understand the technical concerns regarding improperly configured SSL certs and the issue isn't with our boxes but a service we're using. It happens mostly on test boxes rather than prod/stg so we're investigating but needed something to test the APIs.
You can't 'ignore the certificates entirely' for the following reasons:
The problem in this case is that the client didn't even provide one.
If you don't want security why use SSL at all?
I have no doubt whatsoever that many, perhaps most, of these alleged workarounds 'for development' have 'leaked' into production. There is a significant risk of deploying an insecure system if you build an insecure system. If you don't build the insecurity in, you can't deploy it, so the risk vanishes.
The following was able to allow unsafe SSL certs.
Http.postData(url, payload).options(HttpOptions.allowUnsafeSSL,
HttpOptions.readTimeout(5000))
For the newest version of Dispatch (0.13.2), you can use the following to create an http client that accepts any certificate:
val myHttp = Http.withConfiguration(config => config.setAcceptAnyCertificate(true))
Then you can use it for GET requests like this:
myHttp(url("https://www.host.com/path").GET OK as.String)
(Modify accordingly for POST requests...)
I found this out here: Why does dispatch throw "java.net.ConnectException: General SSLEngine ..." and "unexpected status" exceptions for a particular URL?
And to create an Http client that does verify the certificates, I found some sample code here: https://kevinlocke.name/bits/2012/10/03/ssl-certificate-verification-in-dispatch-and-asynchttpclient/.