systemctl status --no-pager -l nginx
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-09-15 14:51:24 UTC; 21h ago
Process: 1075180 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 1075188 (nginx)
Tasks: 18 (limit: 14245)
├─1075188 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
├─1165890 nginx: worker process
├─1165891 nginx: worker process
├─1165892 nginx: worker process
├─1165893 nginx: worker process
├─1165894 nginx: worker process
├─1165895 nginx: worker process
├─1165896 nginx: worker process
├─1165897 nginx: worker process
├─1165898 nginx: worker process
├─1165899 nginx: worker process
├─1165900 nginx: worker process
├─1165901 nginx: worker process
├─1165902 nginx: worker process
├─1165903 nginx: worker process
├─1165904 nginx: worker process
├─1165905 nginx: worker process
└─1165906 nginx: cache manager process
Sep 15 14:51:24 central systemd: Starting nginx - high performance web server...
Sep 15 14:51:24 central nginx: nginx: [warn] protocol options redefined for 0.0.0.0:443 in /etc/nginx/sites-enabled/manuales.castris.com.conf:69
Sep 15 14:51:24 central nginx: nginx: [warn] protocol options redefined for 0.0.0.0:443 in /etc/nginx/sites-enabled/multimedia.castris.com.conf:79
Sep 15 14:51:24 central systemd: Started nginx - high performance web server.
You have explained it to me, and I have replied with the information. However, nothing points to a solution. I'm not going to say anyway, the strangeness of the analysis of the problem.
If it can help well, if it bothers me to say that I feel lost. Well you can see. It's 30 years in Linux. And I certainly feel handicapped in this little mess.
❯ la /home/laravel/web/clientes.aicha.es/public/.well-known/acme-challenge
-rw-rw-r-- 1 laravel laravel 10 Sep 15 09:34 Test_File-1234
ReMINDER. I know what I put in my nginx files, whether they are with Symfony, with Laravel, with Vue, etc.
What it is not is what cerbot puts in its modifications to the nginx files, and I don't know why what worked for months and several renewals stopped working.
There is something very unusual happening which is why the strange requests.
The nginx server block you showed for port 80 (HTTP) is not processing inbound HTTP requests. There must be something else in your system config that is intercepting these. You could prove this by adding an access_log in that server block and check it after making some requests. You won't see them like you should.
Is maybe something in ovh configured to handle HTTP requests? Maybe a CDN?
Or maybe even a firewall?
I see your HTTPS server block uses a Certbot cert in a "swissknife" folder. I see certs for swissknife.ovh that look like they are part of a CDN and which also include the clientes.aicha.es domain. Often, CDN's intercept HTTP requests so could this be the problem?
Your nginx port 80 server block should redirect this to HTTPS but does not. Certbot makes changes to this server block but that doesn't work when this server block does not handle the request.
curl -I http://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 404 Not Found
This HTTPS request works so we know the file is in the right location.
In reality, I have eliminated everything you are talking about from the problem.
1.- Deactivate the cloudflare proxy. So the requests are direct.
t2. Disable the firewall, although I also have to say that given the clear and concise message of nginx and certbot, the issue is not in this, but in nginx. But of course, I have even tried to eliminate the added certbot code, and leave the configuration WITHOUT https, temporarily to see if a new certificate process was created.
So since the renewal date is approaching and on that machine I have my central services, wiki, etc... I'm not going to take any more risks.
On a new instance, I migrate my services, one at a time, certificate to certificate.
I had this same issue and stumbled on your post before I ever had to create mine. Everything seemed to fail and that was my last resort and it worked for me. You could try that since the certificate hasn't expired yet. Mine already expired at the time and all attempts to renew failed.
Because that is horrible advice in this case. They have a working server but cannot renew. Something has gone wrong with their comms routing. Deleting the cert will not fix that and will just cause the nginx server to fail if it does not have a required cert.
Also, unless there's something else under the hood, I think we had the same issue. I had recently moved the website from an old server to a new one a few months ago. At that time, the certificate was still working but I tried renewing, it just wasn't working so I felt that when it expired, I would be able to renew it until I had to come here; thankful for your help and every other person who contributed. Our server was working well 100% running three platforms. I honestly do not think it'll hurt.
Hear me out please: instead of having all services moved somewhere then face the same issue again, why not put one of the websites under maintenance, remove the certificate for that particular domain and reissue.
You were missing a listen statement for IPv6 in your nginx server blocks.
This setup is not using IPv6 although some of their domains are using Cloudflare's CDN which is very different from their others and of course yours.
We also know that HTTPS requests reach their nginx server it is only HTTP requests that fail. So, it is not IPv4 vs IPv6 but more port 80 vs port 443.
Deleting a cert can have serious consequences. This is a live server with a long running history where one of the certs is for multiple domain names. With HTTP requests failing they cannot validate using the HTTP Challenge. They could lose their server for many domain names.
@abkrim Have you changed that listen statement per @rg305 ? Because using IP based listen statements mixed with others can cause the problems we see
It does not look like you have changed it. Or, you still have some other kind of config / routing issue. These should both redirect but only wiki.aicha.es does (the one with the listen for an IP address)