Manual Renewal Failing

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:
www.lsl-technology.com lsl-technology.com

I ran this command:
certbot certonly --manual -d www.lsl-technology.com -d lsl-technology.com

After running the command, I am asked to add the following two txt files with specific content into the files.


Create a file containing just this data:
NIICyQ7K9YLp30qTv54t4vutEXvAmdH_N6ZCAPTnqs0.eiCJBvGKYtMMWMbTeSxmSokVGx8V4tax-GWK-xF9CKA
And make it available on your web server at this URL:
http://lsl-technology.com/.well-known/acme-challenge/NIICyQ7K9YLp30qTv54t4vutEXvAmdH_N6ZCAPTnqs0


Press Enter to Continue


Create a file containing just this data:
Yxrc3eT0CF0XjgAXCaxc30BUFhp6aXkrLh7p1tifMEM.eiCJBvGKYtMMWMbTeSxmSokVGx8V4tax-GWK-xF9CKA
And make it available on your web server at this URL:
http://www.lsl-technology.com/.well-known/acme-challenge/Yxrc3eT0CF0XjgAXCaxc30BUFhp6aXkrLh7p1tifMEM
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet.)


It produced this output:
Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: lsl-technology.com
Type: unauthorized
Detail: 2a05:d01c:4c2:c600:fc34:498e:2999:d536: Invalid response from http://lsl-technology.com/.well-known/acme-challenge/NIICyQ7K9YLp30qTv54t4vutEXvAmdH_N6ZCAPTnqs0: 404

Domain: www.lsl-technology.com
Type: unauthorized
Detail: 2a05:d01c:4c2:c600:fc34:498e:2999:d536: Invalid response from http://www.lsl-technology.com/.well-known/acme-challenge/Yxrc3eT0CF0XjgAXCaxc30BUFhp6aXkrLh7p1tifMEM: 404

Hint: The Certificate Authority failed to verify the manually created challenge files. Ensure that you created these in the correct location.

Ever though the files are present in the relevant directory.
My web server is (include version):

The operating system my web server runs on is (include version):
lsb_release -a
LSB Version: core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy

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):
certbot 1.21.0

I started off trying to do a manual renewal, that failed with challenge issues, I then tried the manual creation and that failed.
I then deleted the certificates and tried to install them from the start and also get the same error.

The DNS points to my server and the site is up and running.

I have also tried reading loads of posts and cannot seem to figure out what is causing the issue.
Could it be that I still have acme records within the DNS config. Should these be removed before trying the installation of the certificates.

Thanks for your help and guidance.
Lawrence

Have you verified the IPv6 address too?

With IPv4 your server is: Server: nginx
With IPv6 your server is: server: LiteSpeed

6 Likes

@bruncsak
How do I do that?

Thanks
Lawrence

1 Like

Execute the following command on the server:

ip -6 address show scope global | awk '/inet6/ {print $2}'

Compare the output of the command with the IPv6 address of the domain lsl-technology.com, [2a05:d01c:4c2:c600:fc34:498e:2999:d536] advertised in the DNS.

2 Likes

running ip a on the dunnsland server I see the following,

inet6 2001:41d0:800:100e::/56 scope global
inet6 fe80::ae1f:6bff:fe1b:94e4/64 scope link

This does not seem anywhere near the same as what you say DNS is presenting.
How can I resolve this?

Thanks
Lawrence

1 Like

Just change the IPv6 address of the names lsl-technology.com and www.lsl-technology.com from 2a05:d01c:4c2:c600:fc34:498e:2999:d536 to 2001:41d0:800:100e:: in the DNS.

2 Likes

Please note that this is basic networking and absolutely not the scope of this Community. A basic understanding of server/network operations is assumed and, if I may say so, a prerequisite for even considering running a webserver.

Also, is there a specific reason why you're using the --manual plugin with the http-01 challenge? The --manual plugin is difficult to automate and other options such as the --webroot plugin are usually a way better choice.

4 Likes

I do have a good understanding of how things work, I am only lost and don't understand why I am seeing issues when trying to register certificates on my domain. I don't understand how my ipv6 address is different from my DNS and my server, that makes no sense.
The reason I was trying the manual route is because the basic route also failed but the failure was saying that the response was not what was expected. I assumed that it could not read the txt file that I placed on the server. The errors provided say nothing about ipv6. It only says that the expected response was not correct.
How can I get more clear accurate logging for what is really causing teh conflict?

Lawrence

That's because Let's Encrypt cannot know if the IP(v6) address is correct or not. It cannot tell you more than it knows, it doesn't have a crystal ball.

It does provide however the IP address used, so one can match that to the expected IP address of the host. I.e.: some basic deduction and investigation is necessary by a human.

I'd like to suggest to revert to the non-manual route after fixing the DNS/IPv6 address issue, as the manual plugin should only be used as a last resort when the other authenticators are not possible.

You can't. You manually need to investigate the DNS settings for your domain name and try to figure out why it doesn't use the IP(v6) address of the server and fix it.

4 Likes