We've tried explaining that for HTTP authentication to work you need a working HTTP site.
We tried placing a test file in the expected challenge location to see if the web server can serve it.
But we are still unable to reach that file:
Please confirm the file exists:
Hello
❯ sudo ps -eF | grep nginx
root 1075188 1 0 11190 10216 12 Sep15 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
www-data 1165890 1075188 0 11379 15076 11 08:44 ? 00:00:03 nginx: worker process
www-data 1165891 1075188 0 11252 7652 12 08:44 ? 00:00:00 nginx: worker process
www-data 1165892 1075188 0 11252 7652 15 08:44 ? 00:00:00 nginx: worker process
www-data 1165893 1075188 0 11252 7652 9 08:44 ? 00:00:00 nginx: worker process
www-data 1165894 1075188 0 11252 7652 4 08:44 ? 00:00:00 nginx: worker process
www-data 1165895 1075188 0 11252 7652 5 08:44 ? 00:00:00 nginx: worker process
www-data 1165896 1075188 0 11252 7652 4 08:44 ? 00:00:00 nginx: worker process
www-data 1165897 1075188 0 11252 7652 8 08:44 ? 00:00:00 nginx: worker process
www-data 1165898 1075188 0 11252 7652 5 08:44 ? 00:00:00 nginx: worker process
www-data 1165899 1075188 0 11252 7652 15 08:44 ? 00:00:00 nginx: worker process
www-data 1165900 1075188 0 11252 7652 4 08:44 ? 00:00:00 nginx: worker process
www-data 1165901 1075188 0 11252 7652 8 08:44 ? 00:00:00 nginx: worker process
www-data 1165902 1075188 0 11252 7652 15 08:44 ? 00:00:00 nginx: worker process
www-data 1165903 1075188 0 11252 7652 4 08:44 ? 00:00:00 nginx: worker process
www-data 1165904 1075188 0 11252 7652 8 08:44 ? 00:00:00 nginx: worker process
www-data 1165905 1075188 0 11252 7652 8 08:44 ? 00:00:00 nginx: worker process
www-data 1165906 1075188 0 11252 7768 12 08:44 ? 00:00:00 nginx: cache manager process
root 1182166 1181966 0 2334 592 4 12:18 pts/0 00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox nginx
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
Docs: https://nginx.org/en/docs/
Process: 1075180 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 1075188 (nginx)
Tasks: 18 (limit: 14245)
Memory: 61.9M
CGroup: /system.slice/nginx.service
├─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[1]: Starting nginx - high performance web server...
Sep 15 14:51:24 central nginx[1075180]: 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[1075180]: 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[1]: Started nginx - high performance web server.
curl https://ifconfig.io
176.31.31.228
Hello
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
total 4.0K
-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.
Best regards
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
Server: nginx
This HTTPS request works so we know the file is in the right location.
curl -i https://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234
HTTP/2 200
server: nginx
content-length: 10
last-modified: Fri, 15 Sep 2023 09:34:50 GMT
test-file
Update:
Oh, not even your "home" page redirects to HTTPS so this problem is not unique to Let's Encrypt
curl -i http://clientes.aicha.es
HTTP/1.1 404 Not Found
Server: nginx
Date: Sat, 16 Sep 2023 14:06:30 GMT
Your help is greatly appreciated.
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.
nothing.
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.
Thanks for your time.
You should put an access_log in the nginx server block for this domain and then review it after making some test requests.
What does that server block look like now because I still get a 404 for your "home" page. Should I have been redirected?
curl -i http://clientes.aicha.es
HTTP/1.1 404 Not Found
Server: nginx
I would check the NAT/routing - where do the HTTP requests go?
Why not remove/delete the certificate and issue a new one? See the reply that I marked as the solution here: "Certbot failed to authenticate some domains (authenticator: nginx)" - #14 by pxfreelance
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.
Your issue was completely different
You are right though.
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 might be right though.
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)
curl -I --header "Host: clientes.aicha.es" http://176.31.31.228
HTTP/1.1 404 Not Found
Server: nginx
Date: Mon, 18 Sep 2023 14:20:27 GMT
curl -I --header "Host: wiki.aicha.es" http://176.31.31.228
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 18 Sep 2023 14:20:34 GMT
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.