Problem with manual authentication

Help
1

My domain is: edidmpd.pl

I ran this command:

sudo certbot certonly --manual --preferred-challenges http --manual-public-ip-logging-ok -d edidmpd.pl

It produced this output:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: edidmpd.pl
Type: unauthorized
Detail: The key authorization file from the server did not match this challenge. Expected "sY2ICHjdC4B_jLTZMeLnVld-ZNnPuAiqrGb_Nd4QPtk._CtP9rVyYz2EBGZ7jexGmDHI5LHPwg4cbns0aWFXJDA" (got "sY2ICHjdC4B_jLTZMeLnVld-ZNnPuAiqrGb_Nd4QPtk.4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8")

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

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): I don't know

The operating system my web server runs on is (include version): I don't know

My hosting provider, if applicable, is: ovh.com

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

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

2

Welcome to the Let's Encrypt Community! :slightly_smiling_face:

Did you add the new challenge file and remove the old one?

is not

Note: You should always remove challenge files immediately after validation succeeds. They are never reused.

3 Likes
3

Using the manual plugin is almost never a good idea. What's the reason why you're performing the challenge manually?

Can you even use the cert once you've got it without root access?

4 Likes
4

Here is an OVH plugin for certbot which let's you complete DNS challenges automatically:

DNS domain validation is very useful when http domain validation is impractical.

3 Likes
5

My plan was to generate the certificate on a different machine where the domain was attached. My main goal is to get a .pfx cert file for the IIS server that is on an another machine than the server on which I want to generate the cert. The domain will be switched to the main server after the certificate is generated. This only needs to work as an temporary solution.

On the server where I want to generate the cert I do not have root priviliges. I tryied to run the command multiple times and every time was the same result. I tested also with the browser what output is when I call it manually and it was correct with the data that certbot has displayed me. I want just to know why certbot receives a thumbprint that is not present in my file on the server.

6

Got it finally working, created a virtual machine on google cloud and binded the domain to the public IP address of the vm, on it I installed apache host server and by using certbot I created the necessary certificate file and private key file. Next by using openssl I created the .pfx file and added it into the IIS server and I looks like it works. Anyway thank you for trying to help me.

1 Like
7

If you're trying to load certificates into IIS on Windows, it's usually easier to use a Windows-based client, like simple-acme or Certify the Web. They can automate the process of installing it easier than whatever custom script you'd need to do to take certbot's output and make the pfx and import it to Windows.

3 Likes
8

Yeah I know that my solution is over complicated but the company for which I had to generate the certificate has limited access to the main router and so I couldn't generate the files on their server, so I needed to use this extra steps method.