we use bluemix-letsencrypt for generating SSL certificates (as mentioned for example here).
When you run the script, at the end of the process, there is mentioned a limitation - you're not able to update existing certificate without downtime. You need to delete the old certificate first and then upload a new one. But this procedure means unacceptable downtime.
The mentioned solution is that we should use IBM Cloud console where should be possible to upload new SSL certs over the old ones, it means without downtime. This solution worked recently (2-3 months ago), but not anymore.
A few days ago I wanted to do the same as I did four times over the last 12 months (every 3 months), but the design of the console has been changed and now it's impossible to do that.
This is really bad. While we use HTTPS Strict Transport Security, any downtime of SSL certificate is critical for us.
Anyone who knows how we could solve this issue?
Thank you.
Related
With KB5018410 Windows update installed in Windows 10 recently, my Delphi REST applications have stopped working. It seems that TLS 1.2 is turned off. Insomnia, Firefox etc can access the URL below, but not a "default" set of TRESTClint/TRESTRequest/TRESTResponse components dropped on a form with the minimal required Properties modifications.
https://yams.ked.co.za/version
Checking boxes under TRESTClient.SecureProtocols also does not seem to make any difference.
How can I get my (very large) REST application going again!?
Check this conversation out on Reddit - Global Protect TLS issue after install of KB5018410
https://www.reddit.com/r/paloaltonetworks/comments/y21chi/some_of_our_users_are_having_issues_connecting_to/
Check your ssl cert and make sure your cert is not valid for more than 1 year 365 days. If it is issued to be longer than a year try switching your cert to one that is only good for 1 year and see if it solves it. That fixed my Palo Alto global protect vpn issue.
My final solution was to use another, 3rd party component (Chilkat) to carry out the REST functionality.
There is also the option of rolling back (and then blocking repeat upgrading) the Windows 10 KB5018410 upgrade.
The problem with the Embarcadero REST components was reported on the Issues site, and has now been elevated from "Reported" to "Open" status.
I've been using cert manager for 87 days now and saw some certs which are due in 3 days (duration of 90 days) are not being renewed automatically. At first, the certificates weren't tagged with a duration or renewBefore spec. This should default to 90/30 according to the documentation.
I've already tried using cmctl to force renew, added the duration and renewBefore specs and spent a lot of time looking at the logs of all the CM pods. Since starting my debugging journey, I saw that the cert indeed got a renewalTime added to it. But the certificates are not being renewed at all. Could it be possible that cert manager isn't checking for certificates to renew?
I've got about 20 which are due this week, and ~100 this month so I would really like this auto renewal to work.
If any configuration is needed, I'll gladly provide additional info.
I am the only developer (full-stack) in my company I have too much work other than automating the deployments as of now. In the future, we may hire a DevOps guy for the same.
Problem: We have 3 servers under Load Balancer. I don't want to block 2nd & 3rd servers till the 1st server updated and repeat the same with 2nd & 3rd because there might be huge traffic for one server initially and may fail at some specif time before other servers go live.
Server 1
User's ----> Load Balancer ----> Server 2 -----> Database
Server 3
Personal Opinion: Is there a way where we can pull the code by writing any scripts in the Load Balancer. I can replace the traditional Digital Ocean load balancer with Nginx Server making it a reverse proxy.
NOTE: I know there are plenty of other questions asked in Stack
Overflow on the same but none of them solves my queries.
Solutions I know
GIT Hooks - I know somewhat about GIT Hooks but don't want to use it because if I commit to master branch by mistake then it must not get sync to my production and create havoc in the live server and live users.
Open multiple tabs of servers and do it manually (Current Scenario). Believe me its pain in the ass :)
Any suggestions or redirects to the solutions will be really helpful for me. Thanks in advance.
One of the solutions is to write ansible playbook for this. With Ansible, you can specify to run it per one host at the time and also as the last step you can include verification check that checks if your application responds with response code 200 or it can query some endpoint that indicates the status of your application. If the check fails, Ansible will stop the execution. For example, in your case, Server1 deploys fine, but on server2 it fails. The playbook will stop and you will have servers 1 and 3 running.
I have done it myself. Works fine in environments without continuous deployments.
Here is one example
I am using Let’s encrypt on my production server to handle SSL certificate.
My website certificate will expire next week so I regenerated it using the letsencrypt-auto renew command (I didn’t set cron task yet)
The last log I get is 2016-08-20 17:12:20,305:DEBUG:certbot.renewal:no renewal failures which mean certificate has been successfully regenerated
But when I go back to my website and check the certificate properties it still says that it will expire next week.
So:
Does Let’s Encrypt wait the last day of certificate to update its new expiration in browser ?
Did my new certificate is not working properly which explain browser still give me next week as expiration ?
Can someone help me to clarify the way certificates expiration date works ?
Thanks for your help !
Thanks to Let's Encrypt community, I have been able to figured out what was wrong: I just needed to reload my Nginx server and it updated the expiration time for certificate !
I'll just follow up here with a bit more information, for those who are looking at this question for answers.
If you have the renew running in crontab, and you have this issue, you can specify command option: --post-hook 'some command'. And that 'some command' should be the shell command necessary to reload your web server.
Though coming late, might be useful to someone.
Even after restarting apache I still had the issue. A full machine reboot solved it for me. This will be useful only if you have full control of the server machine though.
I have a p12 file. This was generated from a DigiCert p7b.
When I import this into my personal store on one machine (windows server, using certificates mmc) it shows me one chain when I view the path.
Using the same file, I import into my personal store on a different machine (also windows, using certs mmc). On this one I see a different path (and in this case it has an expired hop)
Specifically, two hops above my cert the divergence occurs.
Why does this happen? Is there anything I can do to influence that chain (remember its the same p12 that is creating different paths)?
I should also say, I am no expert in this area. I'm a developer that muddles through these security issues when needed.
I had the same issue. Two different windows 2008 r2 servers, same certificate. After standard OS patching one of the servers was sending only the first layer of certificate trust chain (number 0), so the openssl client was failing with the message:
verify error:num=21:unable to verify the first certificate
No idea what was the root cause. I tried to
reassign certificate in IIS
reimport certificate
restart IIS
with no success. What finally helped to fix the issue was the server reboot...
Closing this out.
I'm still a little foggy on why things were working the way they did but some things made sense.
It seems the .p12 was created from a p7b that included some of the intermediate certs. One of the included intermediates was the bad one. This explains why the chain was bad on one machine.
Still not sure how I was able to see a good chain on different machine but I understand why I saw the bad one. It seems the good chain was the fluke and the bad chain should have been expected (I originally assumed the opposite).
I created a new .p12 without the intermediates. Cleaned up all the bad intermediates that were previously imported from the first .p12 in both service user and local machine stores. All seems to be working as expected now with same valid chain on all machines.