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?
Related
I am looking a solution for hours but can't find any. I am using letsencrypt ssl via certbot.
My domain is ektaz.com when I check certificate on browser it says
Expires: 8 November 2021 Monday 16:24:33 GMT+03:00
When I check it from server side with certbot certificates I get result as
Expiry Date: 2021-11-08 13:24:33+00:00 (VALID: 39 days)
But all browsers says certificate is invalid I don't understand why.
Also I have renewed this certificate many times using certbot renew I had no issue so far. I have cleared all cache and tried result is the same. I restarted apache many times. Even restarted server but nothing changed.
Server OS : Ubuntu 20.04 LTS
Your certificate is likely not invalid at all.
There is a simple fix. I'm using nginx configuration style for this example:
ssl_certificate /usr/local/etc/letsencrypt/live/domain.com/cert.pem;
Lines like that need to be replaced by lines like this
ssl_certificate /usr/local/etc/letsencrypt/live/domain.com/fullchain.pem;
Then refresh your server's configuration.
This problem is popping up all over the place, including with both small and large websites.
The root cause is older tutorials for configuration of webservers that served the cert.pem file (because it worked) rather than the fullchain.pem file which makes sure a browser gets the full chain needed to validate the certificate.
Unfortunately, Apple, Mozilla, and some others have dropped the ball and are still using the same intermediate certificate (IdentTrust DST Global Root CA X3) which expired yesterday afternoon at 2:21:40 pm CST to check certificates that were using it before. iOS 15.0 (19A346) is the only released Apple software version that is automatically using the new intermediate certificate even when the server doesn't send the full chain.
The actual intermediate certificate being used by the server is issued to R3 by ISRG Root X1, but unless you configure your server to explicitly tell this to browsers by using the fullchain.pem within the server configuration, then sadly many software companies have dropped the ball and don't do it right on their own.
But once again, this is an easy fix. Just make that slight change to lines in your server's configuration file "cert.pem" -> "fullchain.pem" and you should be fine.
And there's no reason not to keep on using the fullchain.pem file permanently. In fact, even prior to this situation, various networks (college campus WiFi networks are notorious for this) will screw up your certificate's chain of authority unless you use the fullchain.pem file anyway. Let's Encrypt even recommends this now as the only proper way to configure your web server to use certificates.
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.
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.
via Namecheap I have my SSL certificates (POSITIVESSL Comodo) which run on my Nginx webserver to offer https to my clients. This worked like a charm until my certificate expired.
Now I tried to install a new certificate, but whatever I try, the old one is being loaded.
What I did.
Removed all the old certificate files (.key, .crt, .csr)
Using this tutorial creating a new key files.
Entered that file into the Namecheap SSL panel to generate new SSL certificates (which arrived, and show to be valid from 11/26/2012 to 12/26/2013.
Go to my certificates directory, put in the 3 .crt files I got.
Using this tutorial i bundled all the .crt files into 1 .pem file.
Check my nginx.conf to confirm all the paths to the .key & .pem file are correct
Restart nginx
I even tried to change the file names, to ensure they cannot conflict with the old ones, but still my old certificates are being loaded. I have used tools like: http://www.digicert.com/help/ to test the certs, also there the old ones are still being loaded.
Apart from Nginx, should I restart anything else to ensure the new files are being loaded correctly?
Issue has been resolved, the DDOS protection proxy also needed to be updated.