My server will not renew the certificate I think its has to do with /.well-known/acme-challenge/

Help
1

Am I supposed to have a folder named /.well-known/acme-challenge/ on my server I've never hear of it. Why wasn't it in the instructions. Renew always times out. Certbot installed fine since installing we have only updated OS files and PHP. Is it supposed to be an alias for a letsencrypt folder?

My domain is: access.library.newpaltz.edu

I ran this command: certbot renew --dry-run

It produced this output:
sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/access.library.newpaltz.edu.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for access.library.newpaltz.edu
Waiting for verification...
Challenge failed for domain access.library.newpaltz.edu
http-01 challenge for access.library.newpaltz.edu
Cleaning up challenges
Error while running apachectl graceful.

Job for httpd.service invalid.

Unable to restart apache using ['apachectl', 'graceful']
Attempting to renew cert (access.library.newpaltz.edu) from /etc/letsencrypt/renewal/access.library.newpaltz.edu.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/access.library.newpaltz.edu/fullchain.pem (failure)

** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/access.library.newpaltz.edu/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: access.library.newpaltz.edu
    Type: connection
    Detail: Fetching
    http://access.library.newpaltz.edu/.well-known/acme-challenge/iVzgOQ5bYdDlY2Y_uVEdjZXz3lSv-pd3xtw8WKdDACE:
    Connection reset by peer

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.

My web server is (include version): apache 2.4

The operating system my web server runs on is (include version): red hat 7

My hosting provider, if applicable, is: college hosted at SUNY New Paltz

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

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

2

Welcome to the Let's Encrypt Community, Gary :slightly_smiling_face:

Let's see here... :thinking:

That's a first. :astonished: There is already a test file at https://access.library.newpaltz.edu/.well-known/acme-challenge/test

3

Because it's automatically generated by certbot. That's why.

That's a whole different story and has nothing to do with the /.well-known/acme-challenge/ directory.

A "Connection reset by peer" is actually not an error I've seen before here on this Community. It's also not an error I can reproduce from my end: I'm getting the expected "File not found" error if I try to get that challenge file. (The file has been removed by certbot, because it's no longer useful as the challenge has been marked as invalid. This is expected and normal.)

This is a little bit weird though.. You're using the apache installer, which is reloading the currently runnign Apache after it installed a temporary configuration file for the challenge. But somewhere in this process, Apache isn't function very well..

Could you please try the following? Add --debug-challenges to the command line as follewed:

certbot renew --dry-run --debug-challenges

It should tell you something like "Challenges are now loaded, press Enter to continue".. Do not press enter at that point. When certbot is waiting for you to press enter, please check your Apache error logs for possible hints about what's going wrong. Also, you could check systemctl status apache to see if there's a general error with your Apache. Of course that output should be normal before you do this :stuck_out_tongue:

1 Like
4

@Osiris

Maybe in updating the OS some of the configuration got damaged?

5

@GaryO

Can you please share the contents of etc/letsencrypt/renewal/access.library.newpaltz.edu.conf

6

Could be an Apache thingy.. See my edit above.

It will tell you the Apache authenticator and Apache installer were used. (But we knew that already.) It will give you the paths to the files in /live/. It will tell you the account used. It will not tell you anything about webroots, because the webroot plugin isn't used. Not sure how the file can help in this case, as the plugins are selected without any problem and the Apache plugins don't really have (regularly used) configurable options.

7

I concur with your suggestions. Using the debug and checking apache status are great ideas. Good point about not showing the webroot in the conf. An oversight on my part. The apache plugins do have some configurable options, but I've never actually seen anyone use them in the field and I don't know to what extent they're recorded in the conf.

8

True, there are some obscure options to the Apache plugin indeed.. Forgot about those.

1 Like
9

I have yet to see anyone use them, but if they did it would probably be with run and not renew. I would assume they would indeed update the conf if they need not be specified with renew. I might start recommending the apache webroot for Tomcat though. Seen a lot of Tomcat lately.

I'm not getting a timeout here either and Let's Debug reports back clean.

10

I can confirm that it does not create to folder temporarily and as a test I manually made a folder with that path and it does not put any challenge files in it.
systemctl status httpd
Claims fine and happy I didn't copy its output

Output of --debug-challenges does not look much different.
sudo certbot renew --dry-run --debug-challenges
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/access.library.newpaltz.edu.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for access.library.newpaltz.edu
Waiting for verification...

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Challenge failed for domain access.library.newpaltz.edu
http-01 challenge for access.library.newpaltz.edu
Cleaning up challenges
Error while running apachectl graceful.

Job for httpd.service invalid.

Unable to restart apache using ['apachectl', 'graceful']
Attempting to renew cert (access.library.newpaltz.edu) from /etc/letsencrypt/renewal/access.library.newpaltz.edu.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/access.library.newpaltz.edu/fullchain.pem (failure)

** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/access.library.newpaltz.edu/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: access.library.newpaltz.edu
    Type: connection
    Detail: Fetching
    http://access.library.newpaltz.edu/.well-known/acme-challenge/bRW5mnL5PBKcg4zqsG0GNzOOBKSOFXBT7waYrfziqWY:
    Connection reset by peer

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

1 Like
11

Well, technically, the apache authenticator plugin doesn't actually physically create the directories in your DocumentRoot, but adds a temporary <VirtualHost> block in a temporary Apache configuration file with a different DocumentRoot.

When did you check this?

I didn't expect it to be different. I think (and hope) the key here is your Apache. Have you checked the Apache logs during the different phases of the certbot run? I.e., after certbot was started, but before you pressed "Continue" while certbot was waiting and after you've pressed "Continue"?

What could also be interesting if you could keep certbot in that "Challenges loaded. Press continue to submit to CA" state so we might be able to duplicate the "Connection reset by peer" error from the Let's Encrypt validation servers.

1 Like
12

I got it working and updated. I patched some old settings in the old ssl.conf (maybe) & I made that test folder (possibly) & I used the --webroot and path with the renew command and nothing else.
sudo certbot renew --webroot -w /var/www/html/
Yes my server is having an issue gracefully restarting some of the time that I have not figured out but at least I'm out from under the axe of loosing my cert tomorrow and loosing an essential service.
It was Osiris who said "...adds a temporary <VirtualHost> block in a temporary Apache configuration file with a different DocumentRoot."
Different root? BOOM I knew that was another thing I could control with --webroot but did not know I could use in the renew command that easily.

2 Likes
13

The webroot plugin is a powerful alternative to the apache authenticator indeed. My primary concern was a misbehaving Apache webserver, so I thought the main issue was to fix that. But if you're fine with using the webroot plugin, that's great too!

2 Likes
14

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