Configure delay for the webroot plugin

My domains for which I use LetsEncrypt run from a directory on a server in a web hotel. I do not have, not can I get root access to this server, although I can log in via ssh using my personal account. To make my certificates, I’ve installed certbot on my personal Mac (running El Capitan), and I have mapped the root directories on the server to local directories on the Mac using sshfs and Fuse. Then I run “./certbot-auto certonly -d -d …” and choose the webroot option (place files in directories). I get my certificates, then I install them on my web hotel using its administration program called cpanel.

This all works fine except for one detail: I get a lot of timeouts during the webroot part of the operation when certbot is trying to verify that it has control of the right server. I suspect that sshfs simply isn’t quite fast enough, and certbot looks for its .well-known/acme-challenge/ files to be served up before they have been saved.

So to my question: would it be possible to configure the webroot plugin to insert a delay between placing the files in the server and attempting to fetch them via http? I believe this would solve my problem and make the certificate generation more reliable. As it is I must make about 5 or so attempts before I get a successful cert generation.

There’s 2 options for what you can do.

  1. Use manual mode instead of webroot, this tells you what to put in the files, then waits for you to confirm that they are there.
  2. Use one of the alternative clients that doesn’t require root.

As a bodge, obviously it should be possible to add a call to a function like “sleep” in the right part of the webroot plugin. But I don’t like that, here’s why: Delays tend to be a bit fragile. 1 second works today, then a week later it stops, so you try 2 seconds, that works, until one day it doesn’t work either. Not so great.

It should be possible for everybody in the chain you described to wait until they know the file is really there and pass that information along. Some of them might already be doing it, so it feels like the best fix (maybe not the easiest) is to ensure everybody does that correctly.

Probably the certbot client should be using one of the “sync” family of file synchronisation primitives so say that it really absolutely needs for that file to exist now, in webroot mode only of course. And probably sshfs + FUSE should co-operate to ensure they don’t return from such a synchronisation attempt until they’ve ensured the file really exists at the far end of the network.

Anyway, the other good news for you in that CPanel are working on building Let’s Encrypt into their system. So once they do that, and once your host upgrades, there will be a new option where it’s just basically one click to turn on Let’s Encrypt certificates for your site and no more fiddling about with manual steps. But obviously that doesn’t help you today.

Ah yes, thank you cool110, I think manual mode was the default the first two times I ran the program (before it was called certbot), but I am currently not presented with that option from the menu. The options I can see (running version 0.7.0 of certbot) are:

  1. Apache Web Server - Alpha (apache)
  2. Place files in webroot directory (webroot)
  3. Automatically use a temporary webserver (standalone)

While I wait for the cpanel plugin mentioned by tialaramex below, could you please describe how to start the client in manual mode? Meanwhile I’ll look at that list of alternative clients also.

Run it as ./certbot-auto certonly --manual -d

Unfortunately that option does not appear to be supported:

An unexpected error occurred:
ValueError: Invalid header value 'CertbotACMEClient/0.8.0 (darwin 10.11.5\n) Authenticator/manual Installer/None’
Please see the logfiles in /var/log/letsencrypt for more details.

Looking at the logs I get:

File “/Users/peter/.local/share/letsencrypt/lib/python2.7/site-packages/requests/”, line 468, in request
resp = self.send(prep, **send_kwargs)
File “/Users/peter/.local/share/letsencrypt/lib/python2.7/site-packages/requests/”, line 576, in send
r = adapter.send(request, **kwargs)
File “/Users/peter/.local/share/letsencrypt/lib/python2.7/site-packages/requests/”, line 376, in send
File “/Users/peter/.local/share/letsencrypt/lib/python2.7/site-packages/requests/packages/urllib3/”, line 559, in urlopen
body=body, headers=headers)
File “/Users/peter/.local/share/letsencrypt/lib/python2.7/site-packages/requests/packages/urllib3/”, line 353, in _make_request
conn.request(method, url, **httplib_request_kw)
File “/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 1057, in request
self._send_request(method, url, body, headers)
File “/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 1096, in _send_request
self.putheader(hdr, value)
File “/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/”, line 1035, in putheader
raise ValueError(‘Invalid header value %r’ % (one_value,))
ValueError: Invalid header value ‘CertbotACMEClient/0.8.0 (darwin 10.11.5\n) Authenticator/manual Installer/None’

Maybe manual mode is no longer supported on Mac?

You’re running into a bug on OS X that has been fixed in master, but hasn’t been released yet:

This comment has instructions that explain how to run the client with this fix.

OK, thanks, now I’ve got things working again.

For future reference, here’s what I did (after checking out master):

./certbot-auto --no-self-upgrade --debug --manual --dry-run certonly -d my.domain.tld

And it worked the way it used to before the plugins arrived :wink:

Thanks for all the help, everyone!

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