Certbot failure on arch using ddclient to subdomain

Help
#1

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.

#2

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.

#3

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…

#4

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

Or uninstall nginx and start again.

#5

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