I ran this command: lego -d abbradar.moe --accept-tos --http --http.webroot /var/lib/acme/acme-challenge run
It produced this output:
2020/03/22 18:43:01 [INFO] [abbradar.moe] acme: Trying to solve HTTP-01
2020/03/22 18:43:19 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3504535696
2020/03/22 18:43:19 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3504535696
2020/03/22 18:43:19 Could not obtain certificates:
acme: Error -> One or more domains had a problem:
[abbradar.moe] acme: error: 400 :: urn:ietf:params:acme:error:connection :: During secondary validation: Fetching http://abbradar.moe/.well-known/acme-challenge/fvDGo1hBWVN5RiHXJ7Aw7mHgjEWD29xvW-vwOANpK-4: Timeout during connect (likely firewall problem), url:
My web server is (include version): nginx 1.16.1
The operating system my web server runs on is (include version): NixOS 20.09.git.d42d8d5ed94
My hosting provider, if applicable, is:
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): lego 3.5.0
I feel lost because I tested from several unrelated servers at different parts of the world and both curl http://abbradar.moe and curl https://abbradar.moe work. Also I have exactly the same configuration (versions etc.) on other servers which work fine. What do I miss here? Sorry if it’s something stupid.
Yeah, I’d think so to - the problem is, I don’t have any IP filtering going on at all, at least on my part of the infrastructure. My current idea is to run a traffic sniffer on my router to confirm whether this is on my side or somewhere upstream (my ISP??).
% whois `dig abbradar.moe +short`
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '77.37.168.0 - 77.37.247.255'
% Abuse contact for '77.37.168.0 - 77.37.247.255' is 'abuse@rt.ru'
inetnum: 77.37.168.0 - 77.37.247.255
netname: NCN-BBCUST
descr: NKS broadband customers
country: RU
admin-c: NCN7-RIPE
tech-c: NCN7-RIPE
status: ASSIGNED PA
mnt-by: NCNET-MNT
mnt-lower: NCNET-MNT
created: 2008-12-10T15:27:23Z
last-modified: 2010-01-20T13:01:19Z
source: RIPE
role: NCNET NCC Operations
address: National Cable Networks
address: Nagatinskaya str., 1, bldn. 26
address: 117105 Moscow, Russia
org: ORG-NCN1-RIPE
admin-c: RVP-RIPE
tech-c: RVP-RIPE
phone: +7 495 6859542
fax-no: +7 495 6859530
mnt-by: NCNET-MNT
nic-hdl: NCN7-RIPE
created: 2007-03-26T07:46:58Z
last-modified: 2015-10-12T11:53:05Z
source: RIPE # Filtered
abuse-mailbox: abuse@moscow.rt.ru
% Information related to '77.37.192.0/18AS42610'
route: 77.37.192.0/18
descr: NCNET
origin: AS42610
mnt-by: NCNET-MNT
mnt-lower: NCNET-MNT
created: 2009-12-30T09:46:07Z
last-modified: 2009-12-30T09:46:07Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.96 (BLAARKOP)
Nice tool! Didn’t know about it, will keep in mind.
I managed to get the certificates now so it seems to be a connectivity issue after all. I’ll continue to monitor it, maybe place a call to my ISP.
Thanks!
EDIT: Someone PMed me about my solution, so just to make it clear - I just waited for a bit, it seems to be a transient networking problem on my ISP’s side.
