Timeout while retrieving multi-domain certificate

[pemperempem]

Hi there

We’ve been using certbot happily for a while; now I ran into this weird problem: I want to fetch 1 certificate for 8 domains (4 domains, with/without www.), and each time I get a timeout for the last 1 or 2 of them. I tried splitting them in 4+4, just to see if it works with fewer, and it does (for all domains, so I’d infer it can’t be the DNS). It looks to me as if it takes too long if there’s >6 domains… Any ideas?

Cheers, Kim

I ran this command: certbot certonly --standalone -d domain1.ch -d www.domain1.ch -d domain2.ch -d www.domain2.ch …

It produced this output:

My web server is (include version): --standalone

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

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

[_az]

Does the problem also occur if you try to use the webroot authenticator with lighttpd rather than the standalone one?

e.g.

certbot certonly -a webroot -w /tmp/ -d www.berufswahl-umfrage-gl.ch -d berufswahl-umfrage-gl.ch -d berufswahlumfrage-gl.ch -d www.berufswahlumfrage-gl.ch -d berufswahlpass-gl.ch -d www.berufswahlpass-gl.ch -d berufswahl-pass-gl.ch -d www.berufswahl-pass-gl.ch --dry-run

It might help isolate whether the issue has to do with your connection to Let’s Encrypt or with the standalone authenticator.

[pemperempem]

apparently that works: “The dry run was successful.”

[_az]

If that works (against the live server too, without --dry-run), but standalone doesn’t (consistently), then I would guess that there’s a problem with the standalone authenticator on OS X.

[pemperempem]

lighttpd webroot + live server also works. I remembered that I did update certbot and downgraded from certbot 0.21.1 to 0.19.0 now; no problem with --standalone there (didn’t test thoroughly though). Thanks for your help!

[schoen]

I guess you were stopping lighttpd temporarily before running with --standalone in these experiments?

If so, I think I agree with @_az that there’s probably a bug in the standalone implementation under macOS.

[pemperempem]

yes, the procedure is to stop lighttpd and let certbot open its own temporary web server.

[schoen]

@bmw, would you agree that this suggests a macOS-specific bug in --standalone? If so, I can open an issue about it.

@pemperempem, would you be willing to share some logs from /var/log/letsencrypt related to these attempts so that we can confirm what Certbot was trying to do in these cases?

[bmw]

Sure seems that way. I thought it might be AAAA vs A record issues, but the domain it failed on doesn’t have a AAAA record.

Another thought is authz reuse and the domains it’s succeeding for already have valid authorizations. Certbot logs would allow us to see if this is the case.

[pemperempem]

hope this helps. https://pastebin.com/RGAWCsdM

[schoen]

Thanks! That did show a failure to bind port 80.

Would you be willing to try stpoping lighttpd again and running this command?

netstat -pant | grep :80

(I hope those options are the same on macOS as on Linux.)

[pemperempem]

netstat does not work exactly that way on macOS; I did
sudo netstat -ap tcp | grep .80
and
sudo lsof -P -i4 | grep :80

lsof shows connections when lighty is up, none when it’s down; netstat still has some CLOSE_WAIT, but no ESTABLISHED ones when lighty is down.

With certbot 1.19.0 i also get “Failed to bind to :80” in the log, but certbot manages anyway…

[schoen]

@bmw, can you think of more information we should try to obtain here or someone who has an ongoing interest in pursuing macOS-specific fixes?

[bmw]

It’s strange to me you’re getting a connection for some domains and not others when all domains are pointing to the same IP. It’s hard for me to imagine what could be a problem in Certbot that would cause this, but I can’t think of any other relevant questions to ask now.

As for someone who has an ongoing interest in macOS fixes, while we regularly test against macOS, there are no devs currently especially focused on efforts here.