My problem is that my certificat not completely working on my staging environment.
The browser reads the cert on the staging env. , but after several page refresh, it drops and shows the old one with this error : net::ERR_CERT_DATE_INVALID
You should ensure that dns is working fine. Maybe there are multiple distinct address records for the hostname of your staging environment? On subsequent reloads, you may hit different machines.
You probably don’t want to revoke it if it is a copy of your production certificate!
It’s only necessary to revoke a certificate if someone has compromised the private key. Otherwise just deleting it is fine.
If you’re going to restart and try again, I would suggest using tar to copy your /etc/letsencrypt directory so the permissions and symlinks are preserved instead of manually recreating them. It looks like you did that right because certbot certificates worked, but this is often a source of issues.
prod $ sudo tar -cJf certs.tar.xz /etc/letsencrypt
stage $ sudo tar -x certs.tar.xz -C /
You mean in the /etc/apache2/sites-available/ssl.conf ?
If yes, it is configured to use the fullchain and privkey in live directory
I'm connecting to the stage in SSH and HTTPS which encapsulates the TLS protocol and there is no ip load balancer.
I switch between stage and prod env. by editing the /etc/hosts file and commenting the ip of the website
the stage env. has no DNS, you can't access it unless by editing the etc/hosts
Changes in /etc/hosts might not be instant. Look into /etc/nsswitch.conf, section hosts:. If there is a keyword nscdbefore the keyword file, then you have to reset the name service caching daemon (nscd) after touching /etc/hosts.
On the other hand, the browser might also cache dns data. After switching the environment, you should close all instances of it before connecting to your environment again.
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
I already tried to clear browser cache, close all instance and open again the website, always the same result.
At first , the cert works fine, I have the https and all, but after few refresh, the css fails to load, and the valid cert is not recognized and shows me the old one
After refreshing 10K times XD to find all errors I could have, It seems to be “better”
Most of the time, the cert is correct, sometimes it fails, but after refresh get back to normal
4.3 sometimes (rare) no https with cert ok
Resources - active content with certificate errors
You have recently allowed content loaded with certificate errors (such as scripts or iframes) to run on this site.
Resources - content with certificate errors
This page includes resources that were loaded with certificate errors.
Certificate - valid and trusted
The connection to this site is using a valid, trusted server certificate issued by Let’s Encrypt Authority X3.
refresh --> back to step 3, etc etc
In Firefox:
all is fine https / cert good
refresh -->
non secured connexion but with valid cert
refresh -->
connexion is not secured page
error cord : SEC_ERROR_EXPIRED_CERTIFICATE
Wouldn’t it be smarter to just give staging and production different host names instead of juggling the same hostname to different IPs in the /etc/hosts of the client and confusing the browsers that way?
