Failure to get certs

Help
1

below is a copy of the errors I'm getting. I have the subdomain pointing to the vps, but its working. Can someone advise?

INFO - fetching certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for chat.redfoxsound.com
http-01 challenge for element.chat.redfoxsound.com
http-01 challenge for matrix.chat.redfoxsound.com
Waiting for verification...
Challenge failed for domain chat.redfoxsound.com
Challenge failed for domain element.chat.redfoxsound.com
Challenge failed for domain matrix.chat.redfoxsound.com
http-01 challenge for chat.redfoxsound.com
http-01 challenge for element.chat.redfoxsound.com
http-01 challenge for matrix.chat.redfoxsound.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

The correct IP is listed next to the correct subdomains, and main domains accordingly.

1 Like
2

Welcome to the Let's Encrypt Community, David! :slightly_smiling_face:

Let me check a few things... just a minute... :thinking:

5 Likes
3

Basic checks passed...

hmm.... one sec... :thinking:

5 Likes
4

What is the output of this command?

sudo nginx -T

Please put 3 backticks on the lines above and below the output like this:

```
output
```

5 Likes
5

After we review the nginx config [or during], we should also look at why HTTP returns 200 while HTTPS returns 404.
Here is one example:

HTTP 200

curl -Iik http://matrix.chat.redfoxsound.com/
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Fri, 26 Apr 2024 19:57:21 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 11 Mar 2024 19:43:53 GMT
Connection: keep-alive
ETag: "65ef5ef9-267"
Accept-Ranges: bytes

HTTPS 404

curl -Iik https://matrix.chat.redfoxsound.com/
HTTP/1.1 404 Not Found
Server: nginx/1.22.1
Date: Fri, 26 Apr 2024 19:57:26 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 140
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
4 Likes
6

Interesting observation, @rg305. :thinking: I get non-Express 404s for all of the following HTTP requests:

The 404 you identified for HTTPS requests appears to be coming from Express.

I suspect that there aren't server blocks setup to serve actual content for HTTPS requests for the subject subdomain names. I believe these results confirm my suspicions of default HTTPS responses (of 404) for the nonexistent content of the subject subdomain names:

Any request for HTTPS content for the subject subdomain names results in a response body of:

Cannot GET (path)

This, of course, won't matter at present for ACME HTTP-01 challenge requests made via HTTP, since there are no HTTP->HTTPS redirects present yet.

3 Likes
8

I wonder if this is shared hosting?
I see a valid cert from a completely different domain:

---
Certificate chain
 0 s:CN = hayato-technologies.co.za     <<<<<<<<<<<<<<<<<<<<<<<<<
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 18:43:50 2024 GMT; NotAfter: Jun 11 18:43:49 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
---

Name:    hayato-technologies.co.za
Address: 102.130.122.228

Name:    chat.redfoxsound.com
Address: 102.130.122.228
3 Likes
9

I suspect that it is either shared hosting (amongst unrelated users/sites) or dedicated hosting (amongst related users/sites). If the former, how configurable nginx may be could be brought into question. If the latter, it's probably a matter of untangling the nginx configuration.

3 Likes
10

The --standalone method is meant for use when you don't have an existing web server running, but it looks like you do have one, so you might want to use a different method than --standalone!

3 Likes
11

I shoulda noticed that, @schoen. :man_facepalming:

4 Likes
12 
nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/chat.redfoxsound.com/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/chat.redfoxsound.com/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed
13

102.130.122.228 is the IP of a Cloud Container (aka VPS). Unfortunately budget is a big issue for me, as I'm not able to afford the bigger fancy servers, so I just got what I could afford.

But I sincerely appreciate everyone's help and suggestions.

1 Like
14

Thanks. Not sure what other method there is. I guess this will be a bust for now then.... )-: Thanks anyways to you all for your advice.

1 Like
15

Yeah... that means that you'll need to either modify your nginx config to remove the offending port 443 server block so certbot can reinstall it or you'll need to replace fullchain.pem with a dummy/snakeoil/default/replacement cert so nginx can load. You might be able to use certbot certonly --standalone to acquire the replacement cert then restart nginx to get it to load. If you do this, you'll want to update your certbot config for that cert afterwards to use --nginx going forward.

4 Likes
16

The different Certbot methods are described at

https://eff-certbot.readthedocs.io/en/stable/using.html#getting-certificates-and-choosing-plugins

3 Likes
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.