I have a Docusign Connect listener running on an EC2 instance. I setup SSL on this with a self signed certificate. This was working fine but I had to reboot my instance yesterday. After rebooting I updated the endpoint in my connect settings with the new DNS alias. Now I've started getting the below error in connect
Could not establish trust relationship for the SSL/TLS secure channel.
I double checked the cert settings were still setup the same in tomcat and they were. I also tried generating a new cert but no luck. I'm working on the demo environment at the moment which should work (and was working) with a self signed cert.
I can also access the SSL URL directly in the browser
Anyone come across this behavior before or have any thoughts on anything I need to change in my config to get it working again?
An update on this - I'm not actively looking into it but it looks to be a sporadic issue. Not sure if it's just a problem in the demo sandbox or not but having not touched the listener in 3 months some days I see the error and other days everything works as expected. I still haven't been able to find root cause but my guess is that the error message been shown is not the actual issue. Since sometimes it works and other times it doesn't, without changing any settings on the DS side or touching the listener or EC2 instance it's running on, I'm guessing there may be some kind of bandwidth or throttling going on in the demo sandbox. I haven't been able to confirm this though. Will add an update if I figure out what's going on.
Related
Problem: Since Chrome updated a while back (version 58?), I'm not able to access my computer's development Express web server with HTTPS from a remote machine on the same private LAN.
I have created a self-signed certificate on the server (my laptop), and it works great from the same machine via https://localhost:8383 (the local SSL port).
In the past I could bypass the warning on a remote machine on the same network but it has stopped working.
I've gone through the steps of creating a local secure DNS server on my own router with DD-WRT, and self-signed a new certificate with SAN so I could use a DNS host name to access it without specifying an IP address.
I'm able to get to the page after bypassing the message that warns the site's SSL certificate could not be verified. But that's not good enough because while the site will load, the underlying websocket service I'm using on the same port does not work, and so the application loads but is broken on the remote machine. Still works on the local machine because the certificate is valid.
It seems the issue centers around Websockets within Express.
Any guidance would be greatly appreciated! This is a strictly secure environment that's meant to be used on a private network and it makes no sense for me to spend a bunch of money on a public certificate if that even matters.
Thank you.
It appears that the issue is with mobile Chrome and Safari on IOS -- I can get untrusted SSL certificates to work with websockets from another computer on the same network with the latest versions of Chrome and Safari. But on IOS (ipads and iphones), the page will load after being prompted, but Websockets FAIL to function whatsoever.
I've found a couple other people finding this issue.
My workaround for this problem was to revert away from SSL for my private network and completely avoid self-signed certificates.
In a private environment this is OK.
We have 5 Service Fabric nodes running 2 applications in 4 environments in Azure. Our Network team wanted to switch out our cluster certificate so they generated a new one (I believe in the key vault) and swapped it to primary. We updated our project to use the new cert's thumbprint. We successfully authenticated to the cluster and deployed (via Visual Studio) using the new cert, but now the application will not activate. The error we are seeing is:
System.Hosting' reported Error for property 'Activation:1.0:1.0:131965678558388988'.
There was an error during activation.There is already a certificate with thumbprint 123oldCertNumber bound to port 200appPort. New certificate thumbprint specified: 321newCertNumber
Additionally, we tried deleting the old cert which is now in the secondary slot, but it just processes for hours saying "Cluster is updating user certificate." and eventually fails to delete the cert.
Any help would be greatly appreciated!
Here's what worked for me:
I deleted all applications, but did not unprovision them. I then reset all nodes to clear them out. Then I deleted the old cert - this time it worked. I redeployed and viola, it activated no problem. Well, almost, I have one node that is stuck with the same error message. I've tried deleting data and resetting it, but haven't been able to clear it yet.
If both of you applications were using the old certificate then you may have encountered a problem described in documentation describing Upgrading multiple applications with HTTPS endpoints.
When the first application goes to update it will fail to configure the HTTPS port with the new certificate, since the second application is still running and has already configured the HTTPS port with the old certificate. The only path forward is to remove both applications that are sharing the port and then upgrade.
For this reason you may want to consider approaches to prevent this problem in the future. You could:
Combine services from the two applications into a single application, or
Run each application on a different port.
I just finished upgrading my applications to use a new cert and here is what you must do.
I have 3 applications using the one cert.
Instructions
In the Application Manifest, I removed the binding
from 2 of my 3 applications. It is important that you do not remove the binding from all of your apps at once.
I then redeployed the 2 apps with the binding removed.
I updated the 3rd Application with the new cert and redeployed
i then added back the binding in the other 2 applications and updated them to use the new cert and redeployed.
That was all that was needed.
Here is a link to the solution
Renew endpoint certificate
An installed SSL certificate (via Lucee server admin > Services > SSL Certificates) keeps getting lost. We enter the target host name click LIST, see the cert and click INSTALL.
It's all fine for a few weeks the suddenly it just disappears (and our 2 way SSL automation dies). We have no idea why it suddenly just goes though, the cert is valid for another year and there doesn't appear to be a way of manually removing the certs so we are at a loss.
We also don't know where that install process actually stores the cert (in a file, Database, memory) in order to try and monitor it a bit better.
Whats confusing me even more is this is happening across 3 servers (Win 2012).
Each time this happens all we've done is reinstall the cert to Lucee (its already on the cert store on the windows box & the java store) and that seems to resolve it.
Any ideas on why it's happening and how to stop it from happening again?
I have been trying to connect my Node.js Public Bluemix app to a DB2 server which is behind a firewall using the secure gateway service of Bluemix. When I try that by just using TCP everything works fine. I am now trying to use the TLS:Mutual Auth option and I can't make it work.
I followed this tutorial (https://developer.ibm.com/bluemix/2015/04/17/securing-destinations-tls-bluemix-secure-gateway/) and the tunnel seems to be created (I can see that at logs of the gateway client) but no data is coming through.
In the object Options which is a parameter of tls.connect, if I set rejectUnauthorized: true then I get "UNABLE_TO_GET_ISSUER_CERT" while I am using the generated certificates of the destination. If I set rejectUnauthorized: false, then it seems to work and the connection opens but nothing comes through, it just hangs. In both cases, I am using the same code that works when TLS is not set up and is based on the ibm_db node driver for DB2.
Has anyone experience with this, I have been struggling with it for some days now and any help would be much appreciated.
After some discussion, we determined that part of the problem was explicitly stating a piece of the cert chain in the CA, causing the UNABLE_TO_GET_ISSUER_CERT error to be emitted. This can be resolved by either adding the full chain to the CA or not explicitly adding anything to the CA (as the cert is publicly signed).
An underlying issue that was identified is that the ibm_db node driver for DB2 does not appear to work as expected for TLS connections.
Posting this for anybody else running across the same problem.
I was working on a browser client that used stanza.io to connect to an XMPP server (Prosody, in my case). I was using a wss:// connection by default. At some point during development, my client failed to connect at all - it would immediately disconnect silently, without providing any kind of useful error information.
There were no error logs, no error codes, no confirmation dialogs or bars, no indications of what might be wrong.
After hours of debugging, I eventually found the problem; as I was messing around with the configuration of my XMPP server, I had re-generated the SSL certificates for the XMPPd. Since I was using self-signed certificates, this would cause an SSL error. Because I had visited that same URI over HTTPS before, I'd already manually approved the old self-signed certificate - but obviously that approval was no longer valid after regenerating the SSL certificate.
The key to the problem is this: If your SSL certificate causes a warning of any sort, wss:// WebSocket connections will immediately fail, and there is no canonical way to detect this.
As stated above, there appears to be no standardized way to even detect that this problem is occurring, let alone solve it. The best solution to this problem that I have been able to find, is as follows:
If the WebSocket disconnects prior to having received a login confirmation (XMPP-specific), try to make a plaintext ws:// (without SSL) connection to the non-SSL port.
If the plaintext connection succeeds, this means that the server is up - thus the problem is with the SSL certificate. (If the plaintext connection also fails, the server is simply unavailable.)
Display an error to the user, indicating that there was an SSL problem, and that they should check the certificate, with instructions on how to manually approve it.
Provide a target="_blank" link to the wss:// URL, but replacing the protocol with https://. This might be Prosody-specific, but by visiting that URL you will see the SSL warning page. Prosody will display a text that starts with "It works!" after approving the certificate - if the server-side is a custom application, you should display a message saying that "the problem has been solved, you can close this tab now".
In the background, in the main application, keep attempting to reconnect over wss:// every few seconds. Once a connection succeeds, this means the user has approved the certificate. Hide/remove the error and continue the normal connection/login process.
It's far from a smooth process, UX-wise, but it's the smoothest approach I've found. It is not possible to iframe the error page (this was one of my first ideas) - Chrome will refuse to load it at all, Firefox will hide the "Add exception" button, and I'd imagine other browsers exhibit similar behaviour.
Remember that modern browsers do not like self-signed certificates.
Therefore, if your secure WebSocket connection dies before ending the handshake, it could mean that the certificate has not been accepted.
In order to solve the issue, you can:
buy a certificate signed by a Central Authority
simply open in a new
Tab or Window the link of you WebSocket's URI and tell the browser to
trust the connection.
Come back to your WebSocket and it should work.
This is what I did and it worked:
1 - Generate self signed certificate
2 - Create an https websockets server this way