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.
Related
I have a server that hosts a Java backend which has a JavaKeyStore (JKS) that stores a certificate from Lets Encrypt.
The certificate chain looks as follows:
- ISRG Root X1 (valid until 30/09/2024, 20:14:03 CEST)
-- R3 (valid until 15/09/2025, 18:00:00 CEST)
--- api.verumsoftware.com (valid until 31/10/2021, 23:10:36 CET)
When I make a request in Postman I get the following error:
SSL Error: Certificate has expired
I find this odd since each certificate in the chain should still be valid.
Does anybody know what could cause this? When I look up the server on various sites that check whether certificates are correctly installed, they all say it's perfectly fine.
This is a LetsEncrypt issue that occurred on Sep 30 2021. You probably need to patch the OS to remove the offending certificate.
For example this in CentOS.
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4#:%7E:text=So%2C%20DST%20Root%20CA%20X3%20needs%20to%20be,The%20manual%20steps%20below%20are%20no%20longer%20necessary
Or use a non-LetsEncrypt SSL Cert.
Apparently this was an issue with Postman, details can be found here:
https://github.com/postmanlabs/postman-app-support/issues/10338
Updating Postman to version 9.0.5 fixed the issue for me!
There is a very simple fix: install this "new" R3 certificate on the CLIENT -- So, on your iPhone (or other iOS device), PC/Mac, browser ect (tested only of Apple, but should work for Android,ect)
GoTO https://letsencrypt.org/certificates/
find the bullet Let’s Encrypt R3 (below active)
Click on the link called pem (or one of the other types; try a bit for your device)
It will download the cert and/or offer to install it
On iPhone (etc)
Use 'Setting'
A new entry is shown, about the cert
follow it, accept it
Done
On Mac
The file is downloaded
Open: KeyChain acces
File-> Import
Select the file; eg: ~/Downloads/let-encript-r3.pem
follow, etc
optionally: select/config SSL: always trust
Done
In general, there is NO need to install/update software, just one file :-)
Ubuntu server 16.04 PHP7.4 Apache2 running wordpress Geotrust SHA256 certificate
I have started getting the following error
cURL error 60: SSL certificate problem: unable to get local issuer certificate
I have read through and tried most solutions on the many questions on here, but to no avail
The latest 2 i have tried is adding to php.ini the following 2 lines and restarted Apache and rebooted after each one to see if it solves the issue. But it does not
After downloading a fresh copy of cacert.pem The first one i tried was
curl.cainfo = "/path/to/cacert.pem"
Then i tried
openssl.cafile = "/path/to/cacert.pem"
But i still get the same error
Any assistance greatly appreciated.
Many thanks
This is likely to be a server problem ("unable to get local issuer certificate" often is):
Even when using a CA bundle to verify a server cert, you might still experience problems if your CA store does not contain the certificates for the intermediates if the server doesn't provide them.
The TLS protocol mandates that the intermediate certificates are sent in the handshake, but as browsers have ways to survive or work around such omissions, missing intermediates in TLS handshakes still happen that browser-users won't notice.
Browsers work around this problem in two ways: they cache intermediate certificates from previous transfers and some implement the TLS "AIA" extension that lets the client explicitly download such cerfificates on demand.
To figure out for sure if this is your problem, use a TLS test service like perhaps this one: https://www.ssllabs.com/ssltest/
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.
This problem is driving me mad but hopefully to you people it may be simple.
This is what I have done:-
Created a new (self-signed) SSL certificate in Plesk 12 to secure the panel.
Set it to use this as the panel certificate.
Changed the ip address to use this new certificate in Tools/IP Addresses
I have checked the sites ssl certificate on numerous online checkers and they all report the certificate is fine (although it being self-signed).
But whenever I browse to the panel I still get 'Your connection is not private'
The trouble is then that the PEM encoded chain, which I believe to be the certificate it's using, is not the self-signed certificate I created. Then after a certain period of time, approx 5 mins, even when I'm still using the admin it will go to 'Your connection is not private' again and show a different PEM encoded chain.
Please could someone help as this drives me crazy when I'm using Plesk.
The sever is running CentOS 6.6 and the servers default address is sris1.co.uk
Thanks in advance.
Most probably, you are accessing both https://sris1.co.uk and https://www.sris1.co.uk, while certificate is issues for www. domain, and it's understandably failing when you access just sris1.co.uk, and browser thinks, that you are being tricked, since cert is issued for different site.
I've never met such problems in Plesk, so, this is only thing, that I can guess from provided information.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .