Certbot failure on arch using ddclient to subdomain

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
pd.funkysalamander.com

I ran this command:
sudo certbot --nginx

It produced this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for pd.funkysalamander.com
Using default address 80 for authentication.
2019/05/26 10:55:04 [notice] 2878#2878: signal process started
Waiting for verification…
Challenge failed for domain pd.funkysalamander.com
http-01 challenge for pd.funkysalamander.com
Cleaning up challenges
2019/05/26 10:55:17 [notice] 2881#2881: signal process started
Some challenges have failed.

IMPORTANT NOTES:

My web server is (include version):
nginx 1.16.0-1

The operating system my web server runs on is (include version):
Arch Linux

My hosting provider, if applicable, is:
Self

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):
Depends on what you mean: DNS Controlled at FastMail

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

Additional Information:

-Using ddclient for dynamic DNS through nsupdate.info

-The FastMail DNS Control Panel has a single ‘A’ record for mail.funkysalamander.com pointing to the FastMail server’s IP address. There is no other ‘A’ record.

-The FastMail DNS Control Panel has a CNAME record for pd.funkysalamander.com pointing to the ddclient dynamic DNS domain.nsupdate.info

-The LANs router has both ports 443 & 80 forwarded to the VM running nginx

$ dig pd.funkysalamander.com returns first its CNAME pointing to the domain.nsupdate.info, then an ‘A’ record from domain.nsupdate.info to the correct public dynamic IP address on the WAN side of the router.

Hi @NginUS

checking your domain - the domain is completely invisible ( https://check-your-website.server-daten.de/?q=pd.funkysalamander.com ):

Domainname Http-Status redirect Sec. G
http://pd.funkysalamander.com/
66.66.199.25 -14 10.030 T
Timeout - The operation has timed out
http://www.pd.funkysalamander.com/
66.66.199.25 -14 10.027 T
Timeout - The operation has timed out
https://pd.funkysalamander.com/
66.66.199.25 -14 10.023 T
Timeout - The operation has timed out
https://www.pd.funkysalamander.com/
66.66.199.25 -14 10.027 T
Timeout - The operation has timed out
http://pd.funkysalamander.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
66.66.199.25 -14 10.027 T
Timeout - The operation has timed out
Visible Content:
http://www.pd.funkysalamander.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
66.66.199.25 -14 10.026 T
Timeout - The operation has timed out
Visible Content:

No answer, not http, not https.

Checking your raw ip ( https://check-your-website.server-daten.de/?q=66.66.199.25 ) - it’s the same picture.

Domainname Http-Status redirect Sec. G
http://66.66.199.25/
66.66.199.25 -14 10.030 T
Timeout - The operation has timed out
https://66.66.199.25/
66.66.199.25 -14 10.027 T
Timeout - The operation has timed out
http://66.66.199.25/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
66.66.199.25 -14 10.020 T
Timeout - The operation has timed out
Visible Content:

No answer.

Is this - 66.66.199.25 - your current ip address?

If it is a home server? Some ISP are blocking port 80, but your port 443 has a timeout too.

Your dns entries

Host T IP-Address is auth. ∑ Queries ∑ Timeout
pd.funkysalamander.com C m87.nsupdate.info yes 1 0
A 66.66.199.25 yes
www.pd.funkysalamander.com C m87.nsupdate.info yes 1 0
C pd.funkysalamander.com yes 1 0
A 66.66.199.25 yes

are ok. There are a lot of domains with CNAME, that’s not a general problem.

So you must have a fundamental error in your configuration. Or your webserver doesn’t work.

If I had to guess this would be it.

I was trying to get reverse proxying working prior to delving into this. I was so frustrated with my lack of progress on that that I started this hoping it would ‘just work’ with its ‘auto’ configuring.

I wonder now what I might be able to do to undo the nginx mess I currently have that’s preventing this from working, so I can start over with hope of success.

Would a simple ‘pacman -Rsc nginx’ get me to where I need to be for this? I can guess but would likely be wrong on how to revert, so I’ll ask here to be sure.

Thanks…

If your webserver doesn’t work internal, you can try what you want.

Or uninstall nginx and start again.

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