I have installed a new certificate on an existing webserver.
Ran "https://www.sslshopper.com/ssl-checker.html". says the certificate
is 700+ days old.
The domain is "www.infocon-inc.com"
Certificate is SHA2.
Created a free certificated made sure sha256.
using both the configure file and the command line -sha256.
running Apache 2.2+ with openssl 1+
Checked IP Address
checked the firewall https is open port.
restart Apache, everytime I updated the certificate.
Still get "ERR_CERT_AUTHORITY_INVALID" error in the browser.
Site has been up for years.
Any ideas as to where to look for the problem?
The problem was there was in ssl.conf referenced localhost.crt and localhost.key.
Related
Pulling my hair out here. Yesterday I set up an SSL Certificate in IIS10. This is the process I followed:
In IIS, under Server Certificates complete Create Certificate Request (generated server.csr & server.key)
Go to sslforfree.com and start "create certificate" process.
Enter Static IP in Domain box
In Validity, choose paste Existing CSR (paste in contents of server.csr)
Select free 90 day certificate
Choose HTTP file upload and add auth file to virtual share in IIS.
Verified OK.
Download certificate
Back in IIS, select "Complete Certificate Request"
Browse to and select "certificate.crt" file.
Give it a friendly name etc, and save.
Browse to website under sites in IIS, and select Bindings. Choose the IP of the server, the incoming Port, and the newly imported SSL certificate.
Back in sslforfree, check the installation.
Everything all good
So everything was working beautifully, could see the certificate in the browser etc, job done.
Now come to today, and the server is actively refusing requests. Go back to check the installation of my SSL on sslforfree, and it's no longer found. Tried removing and re-adding, but nothing I do seems to get the SSL to be visible.
It's not that the certificate is refused, the browser doesn't even think it's there. Why would IIS suddenly stop sharing the certificate? I am totally stumped.
EDIT
As per the advice below, I set up a DNS name with CloudFlare and pointed it at my server.
I Set up the bindings in IIS to link to the new hostname and removed the old certificate (one for port 443 and this one for port 4443 which the API runs on):
Ports 80, 443 and 4443 are all port-forwarded on the router to my server:
I then downloaded Win-ACME and successfully created the Let's Encrypt certificate, and the renewal task created in Task Scheduler.
SSL Cert now shows in Bindings:
SSL Certificate appears to be all good:
...but when I go to the site, using the new domain name. Same problem... no certificate:
So I'm not sure what the problem is here...
This issue may happens when the imported cert does not have a private key associated. solution would be to import the .CER file to your system(from where certificate is requested) personel store and export it with private key. Then copy the .pfx file to required server and import it from server certificate option under IIS.
And you can refer to this link: The Whole Story of "Server Certificate Disappears in IIS 7/7.5/8/8.5/10.0 After Installing It! Why!".
Thanks to Lex Li, I was able to dig around with Jexus Manager, and IIS Crypto to work out what was wrong.
Seems having TLS 1.2 an TLS 1.3 enabled on my machine at the same time was causing issues. Discovered this using Postman and disabling certain TLS Protocols, eventually getting it to work.
For those of you who may experience similar issues, using this application and setting it to "Best Practices" after disabling TLS 1.3 in my Registry, I finally have it working, with a certificate.
Previously I used RapidSSL certificate. After it expired I moved to Lets Encrypt (free ssl) and installed on my server. But site uses still old SQL certificate after couple of refreshes taking new SSL certificate and resources (css, images, scripts) are not loading gives NET::ERR_CERT_DATE_INVALID error.
I restarted Apache couple of times.
I'm using Ubuntu 16.04.
NET::ERR_CERT_DATE_INVALID means your SSL certificate date is invalid, that is because your old certificate has expired. Check your apache config to make sure that - certificate files mentioned are the desired ones. For detail debugging of your problem, you need to look at your apache server log could be located at /var/log/apache2.
I recently changed my certificate to LetsEncrypt's.
I placed the new certificate in the location of the old one:
cat /etc/haproxy/certs/fullchain.pem /etc/haproxy/certs/privkey.pem > /etc/haproxy/certs/mydomain.com.pem
And in my haproxy.cfg I have:
frontend https
bind :::8443 v4v6 ssl crt /etc/haproxy/certs/mydomain.com.pem no-sslv3
Then I ran systemctl reload haproxy, but it still brings the old one when I access it in my browser or using SSLLabs.
If I use curl -kv mydomain.com it shows the correct certificate.
I had this same issue where even after reloading the config, haproxy would randomly serve old certs. After looking around for many days the issue was that "reload" operation created a new process without killing the old one. The old processes were serving the outdated certs. You can check this by "ps aux | grep haproxy".
Fix
If your environment allows for a few seconds of downtime run "service haproxy stop" until no haproxy processes are left and then start haproxy.
**OR**
Sort by starting time and kill old processes while checking if the service is still running in between.
1 Year later EDIT
Instead of manually doing the fix mentioned above after every reload, we added a "hard-stop-after" for 600 seconds. Made sure to kill all old processes after adding the param and checked the same using ps aux. So now, older processes have to die after 600 seconds, and cannot serve outdated certs.
If you have the old pem file in /etc/haproxy/certs, HAproxy might be using it instead of new one.
I had a similar problem. HAproxy was using expired certificate that was first created for only dev.domain.com with Let's Encrypt. Later I changed certificate creation process to include multiple domains:
domain.dom www.domain.com and dev.domain.com.
The old dev.domain.com.pem was still in /etc/haproxy/certs folder. When I visited https://dev.domain.com, HAproxy used old pem certificate file and Chrome issued a warning for expired certificate.
When I deleted dev.domain.com.pem file and reloaded HAproxy, it started using new certificate and SSL is working correctly again.
My problem was historic and outdated wildcard cert that HAProxy (HA-Proxy version 1.8.19-1+deb10u3 2020/08/01) erroneously picked up and spitted out as outdated subdomain cert, both in the browser and in cURL.
Reloading, restarting, stopping+starting and even upgrading Debian did not help. What did help was to remove the outdated wildcard cert and reload.
My server runs Apache HTTPD 2.2.16 with OpenSSL 0.9.8e on Debian Squeeze runs Roundcube 0.95 on a vhost with an SSL cert. It works fine. The cert will expire on the 21st January. Debian Squeeze has not had updates for years.
I created, like usual a new cert from the same provider ( startSSL) and put replaced the old certs with the new .key and .crt (pem) like I have done every other year. The passphrase on the private .key has been removed.
When I restarted Apache, the SSL serving pages served blank pages.
I did not see errors in the error.log. I could see the access.log showing my browser hitting the site with a 200 response. But Roundcube was not there.
Replacing the .key and .crt with the old versions restored everything.
How else could I debug this?
I am running an EC2 instance on amazon with centos as my operating system.
My SSL certificate expired so I renewed it. For some reason it wasn't saying that it was renewed so I tried rekeying it. Once I did that I downloaded the new crt and chain file form godaddy uploaded to my server and updated my virtual host to point to the new files. I then restarted apache and still when I go to the domain it says that my SSL is expired.
I tried rebooting the server and still no luck.
is there something I am missing?
It ended up that this server was behind a load balancer with just one server so the ssl ticket was being server from the load balancer and not the server! WOW
You don't need to rekey it. You just need to generate a new CSR from the existing key, have it signed, and import the signed CSR the same way you did before.