Can't encode character

I manually modify the file in etc/lets/encrypt/renewal and i can’t regenerate my certificate visibly adding comment in the file moove the position of the error, but even if i open the file in hexadecimal i can’t find the invalid caracter.

How can i regenerate a new file without encoding problem ?

And i’m currently block because of two many invalid authorization, how many time i need to wait to test my certificate again ?

My domain is:

I ran this command:
certbot-auto certonly -a webroot --webroot-path=/var/www/certificate --expand -d -d -d -d -d -d -d -d -d -d -d

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
Using the webroot path /var/www/certificate for all unmatched domains.
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xe9’ in position 282: ordinal not in range(128)
Please see the logfiles in /var/log/letsencrypt for more details.

My web server is :
nginx version: nginx/1.10.0

The operating system my web server runs on is (include version):
Linux version 4.4.0-78-generic (buildd@lgw01-11) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) )

My hosting provider: OVH

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

Thank you by advance,

Hi @AymericHENRY,

(I believe) This is a known issue with Certbot that is in the process of being fixed: UnicodeEncodeError while expanding certificate (ascii) · Issue #4273 · certbot/certbot · GitHub I believe you will want to follow this issue to track when a fix is available.

If the problem did occur because of that bug, the underlying problem is that your webroot authentication isn’t working properly—your web server is responding with a 404 or 403 error when the certificate authority comes to download the file that is meant to be posted as proof of your control over the domain name.

One likely reason for this would be if you have different content on each of those domains (which seems likely from their different names). In that case, each one would need to have its own webroot, because each one is probably serving content from a different directory. Specifying /var/www/certificate would work for at most one of the domains.

You can check this by creating a file /var/www/certificate/.well-known/acme-challenge/test.txt and then seeing, with a web browser, whether that file is visible from,,,, and so on for each of the other domain names. If it’s not, then you’ll need to specify the correct webroot directory for each of them (which can be done with a separate -w option immediately before each -d option).

Once the bug that @cpu mentioned has been fixed, the error message that Certbot displays in this circumstance will be much more useful (but you’ll still have to fix the webroot problem in order to get a certificate).

1 Like

For future reference, the rate limit is 5 failed validations per account per hostname per hour. It's a rolling limit, so you just have to wait until there have been 4 or fewer failures in the last 60 minutes.

You can pass --staging to Certbot to test against the staging API server, which issues fake certificates, but has separate (and higher) rate limits. Then switch back to the production server when everything is working.

1 Like

As a test, I would copy/paste the text from your run command; as it doesn't seem to have any non-ascii char.
Or manually type it all over...

It’s probably not about the command. Certbot can have trouble displaying non-ASCII characters in error messages. The real issue is probably something like, the server returned a 404 Not Found page, written in French or something. Then Certbot tried to display the error, but failed in a second way due to the string conversion bug, unfortunately hiding the original error.

Edit: The traceback in letsencrypt.log may give a good hint about what Certbot was trying to do when it failed (again).


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