My web server is (include version): Linux version 4.19.0-8-amd64
The operating system my web server runs on is (include version): Debian 9
I can login to a root shell on my machine (yes or no, or I don't know): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.9.0
I had this domain managed by Cloudfare in the past but I have now reverted the DNS to be handled by OVH where the website is also hosted.
My issue is that the old and expired certificate is still listed when I have a look here crt.sh | happyblend.fr (id 3673602313) and is still served randomly to some users browsing the website causing confusion.
I have already tried to :
renew the certificate on my OVH server
delete and then create again the certificate
But nothing changed...
If you have any idea how I could get rid of this expired certificate this would be really helpful!
You can't remove certs from crt.sh: it's a certificate transparancy log aggregator and people can search for all recorded certificates indefinitely. It's 100 % separate from the server configuration.
Here is the result for apachectl -S for this domain
port 443 namevhost happyblend.fr (/etc/apache2/sites-enabled/happyblend.fr-le-ssl.conf:2)
port 443 namevhost www.happyblend.fr (/etc/apache2/sites-enabled/happyblend.fr-le-ssl.conf:28)
alias happy-blend.fr
alias www.happy-blend.fr
@JuergenAuer this is just because I have two vhost in my apache configuration to handle redirect. I am using this for other domains on my server with no issue
Here is the VirtualHost configuration I am using. Is there anything wrong with that?
I'm not sure whether reorganizing this will solve your actual problem, but officially VirtualHosts in Apache are supposed to be unique (per name and port); they're not supposed to overlap with each other.
OK thanks @schoen I have followed your advice and had all config under the same VirtualHost it seems to fix the issue as I have no more expired certificate when checking on ssllabs.com!
You can't listen on HTTPS/443 for bad names with the sole intention of redirecting to the correct name, without first having a cert that covers all the bad names.
So that when you want: https://wrongsub.domain.name/ to redirect to https://domain.name/
(or to https://correct.domain.name/)
You must have a cert that covers wrongsub.domain.name or they will get a security popup message and most likely will cancel and not continue through to the correct site.