The file could not be downloaded unfortunately, the problem with the certificate was solved otherwise.
Well.
I've create dir
❯ la /home/laravel/web/clientes.aicha.es/public/.well-known/acme-challenge
ls: cannot access '/home/laravel/web/clientes.aicha.es/public/.well-known/acme-challenge': No such file or directory
❯ mkdir /home/laravel/web/clientes.aicha.es/public/.well-known/acme-challenge
> echo "test-file" > /home/laravel/web/clientes.aicha.es/public/.well-known/acme-challenge/Test_File-1234
And if I try http://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234 browser download file with content test-file
After this... exit too root and
certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: clientes.aicha.es
2: wiki.aicha.es
...
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for clientes.aicha.es
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: clientes.aicha.es
Type: unauthorized
Detail: 176.31.31.228: Invalid response from http://clientes.aicha.es/.well-known/acme-challenge/S_I0cHYi8X0rVj6DSgJQRFmCOBjU-W_11Qy9-77xPwg: 404
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Fail and in debug mode
2023-09-15 09:40:37,526:DEBUG:certbot_nginx._internal.parser:Writing nginx conf tree to /etc/nginx/sites-enabled/clientes.aicha.es.conf:
server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot
server_name clientes.aicha.es;
root /home/laravel/web/clientes.aicha.es/public;
index index.php;
charset utf-8;
access_log /home/laravel/logs/nginx/clientes.aicha.es.log combined;
error_log /home/laravel/logs/nginx/clientes.aicha.es.error.log error;
## Invoiceninja
client_max_body_size 20M;
gzip on;
# gzip_types application/javascript application/x-javascript text/javascript text/plain application/xml application/json;
gzip_proxied no-cache no-store private expired auth;
#gzip_min_length 1000;
# gzip on;
gzip_static on;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_buffers 16 8k;
gzip_types text/plain text/css text/javascript text/js text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss applicatio\
n/x-font-ttf image/svg+xml font/opentype;
# gzip_proxied any;
gzip_disable "MSIE [1-6]\.";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
location ~* \.(js|css|png|jpg|jpeg|gif|mpg|avi)$ {
expires +60d;
log_not_found off;
access_log off;
}
location ~* \.pdf$ {
add_header Cache-Control no-store;
}
if (!-e $request_filename) {
rewrite ^(.+)$ /index.php?q= last;
}
location / {
# try_files $uri $uri/ /index.php?$query_string;
try_files $uri $uri/ =404;
location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
expires max;
access_log off;
}
location ~ [^/]\.php(/|$) {
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php/lientes.aicha.es.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
}
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt {
access_log off;
log_not_found off;
allow all;
}
location ~* "/\.(htaccess|htpasswd|user.ini|php.ini|env|ht)$" {
deny all;
return 404;
}
location ~* "/*.log$" {
deny all;
return 404;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/swissknife.ovh/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/swissknife.ovh/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location = /.well-known/acme-challenge/_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs{default_type text/plain;return 200 _MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs.Br-BNggJ8_ZwacbnJ5_G__2vCy6biKgn_fMyxpIGMLo;} # managed by Certbot
}
server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot
if ($host = clientes.aicha.es) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name clientes.aicha.es;
listen 80;
return 404; # managed by Certbot
location = /.well-known/acme-challenge/_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs{default_type text/plain;return 200 _MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs.Br-BNggJ8_ZwacbnJ5_G__2vCy6biKgn_fMyxpIGMLo;} # managed by Certbot
}
2023-09-15 09:40:38,552:DEBUG:acme.client:JWS payload:
b'{}'
2023-09-15 09:40:38,553:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/chall-v3/264624577906/G_ZIXw:
{
"protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvNzgzNzY1NDkiLCAibm9uY2UiOiAieTVCZUtFUlU4MkloUXI4NTZkMVpYQWFTb0V6dkpvT01fampUQVlfN25fRlhpQXhodUdVIiwgInVybCI6ICJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9jaGFsbC12My8yNjQ2MjQ1Nzc5MDYvR19aSVh3In0",
"signature": "d7AppbsGHuTNWDhJ4INufuxQGAA189lyI6uKp_Wtx2PSCp1Bn7IGuJi9E1umwJozmjlFP2Uz5thc1pvB3uG82tKXsGpIynabx328mHyRB4NncPcuRVaWK3L12QqLsw6MspfcAGiIrYQjHwiIJxYzI6He3I4bSIQE6GRf4T1hJibFNT6IZG929yI70s1iNrxppF-jm_QohCcrtJpQITr13rLRu0sg7JIC1dRELux8pZ4Mu0oWL556yIUaK_OsONCnHEC43qgAgq8oYZgtlT-okMlSVc1UTXsDGvuieoWKsecjJ3rZrL3um3-U16QLpL25d6j67uicAAXAJqa5E_QDGg",
"payload": "e30"
}
2023-09-15 09:40:38,688:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/chall-v3/264624577906/G_ZIXw HTTP/1.1" 200 187
2023-09-15 09:40:38,689:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Fri, 15 Sep 2023 09:40:38 GMT
Content-Type: application/json
Content-Length: 187
Connection: keep-alive
Boulder-Requester: 78376549
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index", <https://acme-v02.api.letsencrypt.org/acme/authz-v3/264624577906>;rel="up"
Location: https://acme-v02.api.letsencrypt.org/acme/chall-v3/264624577906/G_ZIXw
Replay-Nonce: 3kCpO4BeacrMy22s7zML-Cc-mAnFdCLhOqsNU_dus3YsPU-ksq4
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
{
"type": "http-01",
"status": "pending",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/264624577906/G_ZIXw",
"token": "_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs"
}
2023-09-15 09:40:38,689:DEBUG:acme.client:Storing nonce: 3kCpO4BeacrMy22s7zML-Cc-mAnFdCLhOqsNU_dus3YsPU-ksq4
2023-09-15 09:40:38,689:INFO:certbot._internal.auth_handler:Waiting for verification...
2023-09-15 09:40:39,691:DEBUG:acme.client:JWS payload:
b''
2023-09-15 09:40:39,692:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/264624577906:
{
"protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvNzgzNzY1NDkiLCAibm9uY2UiOiAiM2tDcE80QmVhY3JNeTIyczd6TUwtQ2MtbUFuRmRDTGhPcXNOVV9kdXMzWXNQVS1rc3E0IiwgInVybCI6ICJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9hdXRoei12My8yNjQ2MjQ1Nzc5MDYifQ",
"signature": "SLs4VzpDOaChi5p9uV2GRvt8rn6DGgiiyu8pvXoxIv-E3QYI8KreRQ18m4oRj6tWNWpfFbs_jSKihPfkg4wuwgRv9C12YTlw9mrKkoENSNouYMqb1OfyyK-Y7xeOb6dFf4V6p7PnZEH4NqPHw5HPb-LK8fijdMaVhOIh_FmGT4_It9B-SJXuJKXGbOdPKFXQ4r3dOH2F_hfuNcxdQZp3F3iEp3N_PV3tiAFiLXtx5UXg-q_311dx_X3_AQQ-0YQoE5gubjJiQXHnLD6EmKS4bTxLke1cLYVUYPpRMdpUKUdkp-uEJxEu4TturySF6FzpG7XtPTtvdFwduzMvdi6CqA",
"payload": ""
}
2023-09-15 09:40:39,825:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/264624577906 HTTP/1.1" 200 1036
2023-09-15 09:40:39,825:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Fri, 15 Sep 2023 09:40:39 GMT
Content-Type: application/json
Content-Length: 1036
Connection: keep-alive
Boulder-Requester: 78376549
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: y5BeKERUsLx34X_AL7x7yzW6RY2dPqbJ_z0Wi269nJHrdHWmcy4
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
{
"identifier": {
"type": "dns",
"value": "clientes.aicha.es"
},
"status": "invalid",
"expires": "2023-09-22T09:40:36Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "176.31.31.228: Invalid response from http://clientes.aicha.es/.well-known/acme-challenge/_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs: 404",
"status": 403
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/264624577906/G_ZIXw",
"token": "_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs",
"validationRecord": [
{
"url": "http://clientes.aicha.es/.well-known/acme-challenge/_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs",
"hostname": "clientes.aicha.es",
"port": "80",
"addressesResolved": [
"176.31.31.228"
],
"addressUsed": "176.31.31.228"
}
],
"validated": "2023-09-15T09:40:38Z"
}
]
}
2023-09-15 09:40:39,825:DEBUG:acme.client:Storing nonce: y5BeKERUsLx34X_AL7x7yzW6RY2dPqbJ_z0Wi269nJHrdHWmcy4
2023-09-15 09:40:39,826:INFO:certbot._internal.auth_handler:Challenge failed for domain clientes.aicha.es
2023-09-15 09:40:39,826:INFO:certbot._internal.auth_handler:http-01 challenge for clientes.aicha.es
2023-09-15 09:40:39,826:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: clientes.aicha.es
Type: unauthorized
Detail: 176.31.31.228: Invalid response from http://clientes.aicha.es/.well-known/acme-challenge/_MXwcsg4HihLPxD7NWb52c-B6WNVSN8YkkYEotUkGOs: 404
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
2023-09-15 09:40:39,826:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
2023-09-15 09:40:39,826:DEBUG:certbot._internal.error_handler:Calling registered functions
2023-09-15 09:40:39,826:INFO:certbot._internal.auth_handler:Cleaning up challenges
2023-09-15 09:40:41,320:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/snap/certbot/3024/bin/certbot", line 8, in <module>
sys.exit(main())
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/main.py", line 19, in main
return internal_main.main(cli_args)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/main.py", line 1864, in main
return config.func(config, plugins)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/main.py", line 1447, in run
new_lineage = _get_and_save_cert(le_client, config, domains,
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/main.py", line 141, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/client.py", line 517, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/client.py", line 428, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/client.py", line 496, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/snap/certbot/3024/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
2023-09-15 09:40:41,321:ERROR:certbot._internal.log:Some challenges have failed.
Is that test file still there? Because I cannot see it
curl -i http://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 404 Not Found
Server: nginx
Date: Fri, 15 Sep 2023 10:47:52 GMT
3 Likes
https://diwan.tamainut[.]net/index.php/s/DQGJLEWEoexDsYK
When put in the browser, browser say: Save file.
logs:
❯ cat /home/laravel/logs/nginx/clientes.aicha.es*log | grep .well-known
81.32.57.118 - - [15/Sep/2023:09:35:01 +0000] "GET /.well-known/acme-challenge/Test_File-1234 HTTP/2.0" 200 10 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
81.32.57.118 - - [15/Sep/2023:09:37:27 +0000] "GET /.well-known/acme-challenge/Test_File-1234 HTTP/2.0" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
81.32.57.118 - - [15/Sep/2023:14:19:16 +0000] "GET /.well-known/acme-challenge/Test_File-1234 HTTP/2.0" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
I did not look at your MP4 but did you use HTTP to get the file? Or HTTPS?
Because it needs to work with HTTP but only works with HTTPS
curl -I http://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 404 Not Found
Server: nginx
curl -I https://clientes.aicha.es/.well-known/acme-challenge/Test_File-1234
HTTP/2 200
server: nginx
content-type: application/octet-stream
content-length: 10
last-modified: Fri, 15 Sep 2023 09:34:50 GMT
3 Likes
Server is active.
Configuration, is already modified by cerbot.
Redirect to HTTPS is configured by cerbot.
server {
if ($host = clientes.aicha.es) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name clientes.aicha.es;
listen 80;
return 404; # managed by Certbot
}
I'm lost.
I don't understand anything.
1 Like
Oh, sorry, my mistake. The nginx authenticator works differently than webroot and does not use challenge files. A 404 is the expected response with HTTP in this case. A 404 with your server block is wrong. It should have redirected to HTTPS.
Can we check that only one nginx is active? The Certbot log looks correct and should have returned the correct value.
Show results of these:
sudo ps -eF | grep nginx
sudo systemctl status --no-pager -l nginx
curl https://ifconfig.io
3 Likes
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:
2 Likes
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
1 Like
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
2 Likes
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
4 Likes
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.
1 Like
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
3 Likes
I would check the NAT/routing - where do the HTTP requests go?
3 Likes
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
3 Likes
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.
3 Likes
@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
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.