I created a self-signed certificate in a local pc and now I can't access to the localhost showing the following error in both chrome & firefox. There is no option to accept the risk and continue.
I tried removing the generated cert and key files but the issue is still there.
Is there way to rollback that change? Or any other way to continue.
OS: OpenSUSE Thumbleweed
HSTS is blocking you, so clear HSTS config in used browser for used domain (locahost). Random blog post how to do that: https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
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 :-)
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 have a website with two different certificates. One for official use so the user doesn't see a self-signed alert. And one for internal use for private subdomains (for phpmyadmin, roundcube and so on). These subdomains are only for admin use, so it seems useless to me to spend money on a wildward-certificate. Therefor the wildcard-Certifitae is Self-Signed and I have memorized the hash.
Also I got an etherpad-Installation on that server on a different port than http (not a difefrent subdomain). Etherpad now seems to send this header "Strict-Transport-Security: max-age=31536000; includeSubDomains" which is just dumb, because i couldn't find an option to turn off the "includeSubDomains".
Now when I was in my pad and then try to use my admin-Subdomains I get an Error because of HSTS, without the option to set an exception and therefor these are now unusable for me.
Does somebody has an idea how I can get rid of the "includeSubDomains" in the etherpad installation?
I would be glad if someone could help me. Thank you.
It's a tad old, but I would like to point out the better alternative: install the certificate of the (self-signed) CA that you used to sign you own certificate as a trusted CA in your browser.
I just share the CA certificate on my webserver, and download/install it using the IP-address to avoid the HTST-trigger. You can point your browser to
http://1.2.3.4/my_certificate.pem
and your browser will ask you for what you want to use that certificate. If you set it to be allowed to sign websites, and the CN in your certificate matches the hostname your using it for (roundcube, phpmyadmin, etc), your browser will happily accept your self-signed certificates, even when HSTS is enabled.
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 .
I have open ssl installed on the server, all the key ,csr and crt on the server. Configured apache conf to the correct path for key and cert but i don't see a lock in the url(firefox 3.6.2).In chrome it shows https crossed out with red.Does this mean the certificate is not working properly? I have apache2 as the web server.
tls provides both encryption and authentication.
Encryption means that outsiders are unable to read your traffic.
Authentication means that you are confident of the identity of the host your are communicating with.
If chrome crosses out the https, it means that you are using tls, and you have probably set up encryption properly, but chrome is not confident in the authentication of the server. Typically, this is caused by an untrusted certificate; either the subject does not match, or the CA is not trusted.
If you are using a self-signed cert, then it's probably an untrusted CA. Installing the CA into chrome should fix the problem.
I face same problem some time ago that I have installed the SSL certificate successfully but still it show cross on browser address bar, I found the issue was caused due to a image and a javascript file which was included as absolute HTTP url. I change absolute URL to relative and now both files were loading over HTTPS and browser show green bar.