Automating the uploading to .well-known/acme-challenge

Server
1

I’m using letsencrypt-auto, as follows (On MacOS using Terminal):

letsencrypt-auto --debug certonly --email [email] -a manual --rsa-key-size 4096 -d domain1 -d domain2 [etc] -m [email]

For each prompt of Create a file containing just this data: I’m copying pasting, creating the appropriate file and uploading per instructions.

I’d prefer to automate those steps, but haven’t yet uncovered the option to do that. Closest thing I’ve found so far was Serverco’s suggestion to use GetSSL, which I’ve used on a local machine, not to upload to a remote server. Not seeing how it would interface to upload to .well-known/acme-challenge.

2

Are you running Certbot on the same system as your web server? The reason it’s asking you to do this manually is that you’re using the manual authenticator with -a manual. If instead you used webroot, this would let you specify your web root directory, where Certbot will create the .well-known/acme-challenge directory (if it doesn’t already exist) and place the challenge file, as well as clean it up when done.

If, for some reason, you are not running Certbot on the same machine as the web server, you could use the --manual-auth-hook and --manual-cleanup-hook flags to specify a script that will do this for you.

1 Like
3

Thanks jared.m

'Are you running Certbot on the same system as your web server?'

No. Reason: Was unaware that was possible (I'd presumed, being a shared hosting env. meant it wasn't an option)

The webroot / manual-auth-hook, approach seems intriguing. I'd imagine it would have to run as follows:

  • webroot option causes 'acme-challenge' files get stored to a specified local folder.
  • manual-auth-hook script is written to upload all the locally-saved 'acme-challenge' files to the appropriate .well-known/acme-challenge folder on the host.
  • Certbot then does the acme-challenge authentications.

Have I properly described the order of events? (From the 'Pre and Post Validation Hooks' documentation you provided I wasn't immediately able to determine that this was the case)

4

Hi @ovunque,

For GetSSL (and I think also for acme.sh) I believe this is called “remote webroot”. Does that help at all?

5

You should be using either the webroot plugin or the manual plugin with or without the available hooks as you have described.

If you're already running a webserver configured for the desired domain on the same server, there's not really a reason not to use the webroot plugin.

6

@schoen I believe this is called “remote webroot”. Does that help at all?

I think so. Slowly figuring this out. Thanks!

@Osiris there’s not really a reason not to use the webroot plugin

Agreed, other than stubborn determination

Actually the real challenge to all of this has been testing. I generally try out a few ideas every 3 months, each expiration. Not exactly the most expedient way to understand what's possible. Is there a way to dummy test the process?

9

For testing you're recommended to use the staging environment:

It issues non-publicly-trusted certificates using much the same technology as the regular CA, with much higher rate limits.

You don't have to wait for certificates to expire to renew them. Certbot normally tries to renew 30 days before expiry but you can make it try sooner with --force-renew or by editing the renew_before_expiry value in the individual certificate's renewal configuration file. You can have several certificates valid for the same names at the same time, as long as you stay within the rate limits for the service that you're using.

10

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