Acme.sh not writing to .well-known/acme-challenge/

Domain: vps61983.inmotionhosting.com

I ran this command: .acme.sh/acme.sh --renew -d 'vps61983.inmotionhosting.com' --webroot /var/www/vps61983.inmotionhosting.com --log

It produced this output: error:Fetching http://vps61983.inmotionhosting.com/.well-known/acme-challenge/[token] : Connection refused

My web server is (include version): NodeJS

The operating system my web server runs on is (include version): CentOS

My hosting provider, if applicable, is: inmotionhosting

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): acme.sh v2.8.8

From what I can tell acme.sh says it's writing the token (there's no error) and the path it is writing to is the proper one

eg writing token:[token] to /var/www/vps61983.inmotionhosting.com/.well-known/acme-challenge/[token]

There's no indication there's an error, but the file never appears in the directory specified.

Question: Does acme.sh erase the token file on the connection refused?

1 Like

The --webroot parameter tells acme.sh where the root folder is for that FQDN.
You should place a test text file there to ensure it matches and the test file can be accessed form the Internet.

Connection refused should have nothing to do with acme.sh (when not run in --standalone mode).
The web server or the firewall/router may be blocking those incoming connections.
Here, also, you need to ensure the Internet can reach your site before running any ACME client.

1 Like

My mistake. You are 100% correct. The server was not responding. My impression was the file was not being created, tripping up the server. But this suggests the file was being created, but then deleted, so I wasn't seeing it. Does that sound correct?

1 Like

And completely off this exact topic but related to your request.
Any use of other peoples domains (without prior consent) amounts to domain spoofing.
Sure, they set themselves up for this when they provided you with an IP and a working for and reverse DNS entry.
But you must understand that they can change the rDNS record at any time and also the forward DNS record.
So you should be using a domain name under your control (or an FQDN from a domain that has given you their consent to use - like with DDNS service providers).

UNLESS
This is a complete test environment.

1 Like

Yes, files are cleaned up after each use - they serve no other purpose (can't be reused).

1 Like

RE "Domain under my control": Yes is a test environment and yes, it's a domain provided by the hosting company. Wasn't going to be used in production, but always good to be thinking this stuff through.

RE: "files are cleaned up after each use": Thanks. It was my server code was the cause of the error. Not finding the leftover file made me think it hadn't gotten written in the first place.

2 Likes

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