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
Related
I am trying the simplest example I can, pulled directly from their website. Here is my entire html file, with code taken exactly from https://peerjs.com/index.html:
<script src="https://unpkg.com/peerjs#1.3.1/dist/peerjs.min.js"></script>
<script>
var peer = new Peer();
var conn = peer.connect('another-peers-id');
// on open will be launch when you successfully connect to PeerServer
conn.on('open', function(){
// here you have conn.id
conn.send('hi!');
});
</script>
In Chrome and Edge I get this in the console:
peerjs.min.js:64 GET https://0.peerjs.com/peerjs/id?ts=15956160926060.016464029424720694 net::ERR_CONNECTION_REFUSED
In Firefox I get this:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://0.peerjs.com/peerjs/id?ts=15956162489620.8436734374800061. (Reason: CORS request did not succeed).
What am I doing wrong?
#reyad has requested "a full trace of requests and responses". Here's what I see in my network tab in Firefox:
And here's Chrome:
And a tiny bit more Chrome:
[Note: It would have been better if you could provide a full trace of requests and responses. This problem may occur for several reasons. I'll state two solutions. So, try those. If those doesn't work, provide full trace of requests and responses.]
1. First Solution:
Sometimes, this type of error occurs because of self-signed certificate. To solve this problem, open developer tools/options, then go to network tab. You'll see a list of requests. Select the request which was failed because of CORS(i.e. which gave you this Reason: CORS request did not succeed). Open it(i.e. click it). If your problem is related to cert you'll see the following error message:
AN ERROR OCCURED: SEC_ERROR_INADEQUATE_KEY_USAGE
To solve this problem, go to url that is the reason of this problem and accept the certificate manually.
2. Second solution:
Check the request(which is the reason of CORS) in the network tab of developers tools/options(same as described in 1. First Solution). You'll find a Transferred column. See, what's written in the Transferred column of the failed request. If it is written Blocked By Some Ad-Blocker, then disable the Ad-Blocker. Your request will work fine.
[P.S.]: These solutions are proposed on assumptions. Hope these works. If these two do not work, then please provide more info about requests and responses. And also check this.
3. Third and final solution:
[Note: This solution may not solve your problem directly, but it'll give you alternative solution and also insight about what your problem is and how to work around it]
Before reading the solution below, read this to understand how Access-Control-Allow-Origin works(it is the reason for CORS error).
Let me first explain how peerjs works:
PEERJS works based on PEER ID. So, you've to get some PEER ID either from the PEERJS CLOUD SERVER or you've to provide yourself one in the PEER CONSTRUCTOR i.e. new Peer("some-peer-id"). Peer id has to be unique, cause its necessary to detect all the users uniquely. And, peerjs uses this PEER ID to send and receive data from user to user.
Now, you should know that, you're using PEERJS CLOUD SERVER to get/generate unique peer id which is the default server PEERJS uses unless you specified some other server to use.
Now let me explain why you're facing this problem:
As you already know how CORS works, you may have already guessed, that https://unpkg.com/peerjs#1.3.1/dist/peerjs.min.js(the downloaded js file) is calling https://0.peerjs.com to retrieve/generate new unique PEER ID. But, this request by https://your.website.com does not have Access-Control-Allow-Origin access for some reason, it may also be a middleware problem. So, its difficult to tell where the problem is actually occuring. But one thing for sure, it's not your fault of writing code :D.
I hope all the concepts is clear to you I've stated above.
Now, to solutions:
Alternative-appraoch-1 (Using PEERJS CLOUD SERVER AND Your own provided id):
In this approach you've to generate your own unique PEER ID. So, "https://your.website.com" does not have to call "https://0.peerjs.com" for unique peer id. [Note: make your peer id large enough so that its always unique, at least 64 chars long]
In this way, you can avoid the CORS problem.
Update:
I just saw an new issue in github, which says the public peerjs cloud server is now unstable or does not work properly. It just gives error like: Firefox cannot establish a connection with the server at the address wss://0.peerjs.com/peerjs?key=peerjs&id=123222589562487856955685485555&token=ocyxworx62i and in Chrome: Error in connection establishment: net::ERR_CONNECTION_REFUSED. For details check here. So, its better, you use your own server(see the next approach).
Alternative-appraoch-2 (Using your own peerjs server):
You can host your own peerjs server instead of PEERJS CLOUD SERVER. In this way, you can allow access to anyone/any website you want. If you want know how to host a peerjs server, you may visit here.
[P.S.]: I have studied pearjs issues in github. After reading all those issues, it seems, it is better to use your own server rather than using pearjs cloud. There are a lot of various problems with each new release of peerjs. And mostly related with connection with peerjs cloud and also peerjs cloud is not stable I guess. They were hosting it in 0.peerjs.com:9000 before(not secure). But now in 0.peerjs.com:443.
I haven't use peerjs before nor set up peerjs server. If you want to set up one, I hope the community would be able help you on how to do that properly.
What I understand from your question is that there is an issue of (CORS => Cross-origin resource sharing ), Maybe what I am suggesting is not very intuitive.
First : download the "https://unpkg.com/peerjs#1.3.1/dist/peerjs.min.js" in your local directory . and then incklude the local javascript code to the html.
like: <script src="./peerjs.min.js"></script>
Second :
you are using var peer = new Peer();
but please provide an extra unique id from your side. for example, I just created a random id and provided it.
StackOverflow link: https://stackoverflow.com/questions/21216758/peerjs-set-your-own-peerid#:~:text=1%20Answer&text=Provide%20a%20peer%20id%20when,to%20under%20Create%20a%20peer.
var a_random_id = Math.random().toString(36).replace(/[^a-z]+/g, '').substr(2, 10);
var peer = new Peer(a_random_id, {key: 'myapikey'});
Third : the best option is to run PeerServer: A server for PeerJS of your own.
If you don't want to develop anything, just enter a few commands below.
Install the package globally:
$ npm install peer -g
Run the server:
$ peerjs --port 9000 --key peerjs --path /myapp
Started PeerServer on ::, port: 9000, path: /myapp (v. 0.3.2)
Check it: http://127.0.0.1:9000/myapp It should return JSON with name, description, and website fields.
details:https://github.com/peers/peerjs-server
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.
I just got this error while trying to do OAuth with Box.com.
BoxOAuthException:
Message: {"error":"invalid_grant","error_description":"Current date\/time MUST be before the expiration date\/time listed in the 'exp' claim"}
Wondering if I have a time sync problem with my server. Maybe my server's network time is out of sync or something.
Anyone ever see this before?
"This error happens when the Unix time on your local machine and the Box server are out of sync. " - via Murtza
https://community.box.com/t5/Developer-Forum/Getting-Please-check-the-exp-claim-Exception/m-p/23843/highlight/true#M969
A few weeks ago this error started popping up.
Set-PSRepository : The specified Uri 'http://*****' for parameter
'SourceLocation' is an invalid Web Uri.
Please ensure that it meets the Web Uri requirements.
I'm not sure how to fix this short of uninstalling Powershell. There is a workaround available on StackOverflow but it's clunky and will not work for me long term.
Frankly I'd rather just find where the PSRepositories are stored and edit the files manually when I need to.
The answer to this other question should help: Invalid Web Uri error on Register-PSRepository
It involves registering the repository using a local path first, then updating it to point to the URL.
Had the same issue,
for me it was an expired certificate at my own repostitory. Exchanged the certificate and the error was gone.
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/.