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?
Related
I have installed my SSL certificates on Glassfish 3.2 and everything works as it is supposed to.
I am facing a very strange problem: On server restart, SSL does not work, but when I click the save button on the web interface of the listener, without making any further changes, it immediately starts working!!!!
Any ideas???
PS. All passwords for the certificates and the master-password are the same.
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
So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.
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.
On a customer's internal network, I can make a request to my SSL site using IE6 SP1 (on Win2K) and see one cert validation requests, but if I use IE6 SP2 (on XP) 13 separate cert validation requests get fired off. Needless to say, this slows down my page load a lot.
Firefox loads the page just fine with no unnecessary cert validation requests.
The server is Apache running a pretty new lampp stack. All the server certificate / CA chain configurations seem to be fine (users can authenticate w/ trusted certs, the system can communicate to other systems with that server cert, etc.)
Is there anything I can do from a configuration standpoint? Any other ideas at all?
I'm guessing that "upgrade IE" is off the table, right? You're probably trying to find a way to support IE 6.0, SP2, with XP, so your users can use this version.
OK... one thought is trying to mess with the SSL configuration. As I remember, SSL has a number of settings that can be used and perhaps you can change one of them on your server and get a different behavior. It might be worth it to research what's happening during the SSL Handshake on the working and not-working versions of IE 6.0. I favor Ethereal, a free network traffic watching tool that will capture the SSL. It can't decrypt it easily, but you can at least see the first few messages that happen in the clear. It might give an inkling into why all these validation requests are coming in.