Hello! Ask for a help.
I’ve got 2 projects in the folder.
For first of them I managed to get a cert successfuly.
Then I only change in the last command the domain and a folder and get an error:
“UnicodeEncodeError: ‘ascii’ codec can’t encode characters in position 255-260: ordinal not in range(128)”
The command is:
./certbot-auto certonly --webroot --agree-tos --email user@gmail.com -w /projects/project-two.ru/public_html -d project-two.ru
So, if it happens only with project-two, it’s ok with nginx paths. I tried to check symbols in paths, but they are all latin, full-stop and 002D HYPHEN-MINUS
What else can matter?
Can the script check the domain which already has SSL installed?
The log: http://joxi.ru/J2b6wKgSXoQBQ2
It’s a little confusing to understand exactly what’s happened in this case: can you clarify a bit more about how the two different errors are related?
The link you gave shows an error message from the Let’s Encrypt certificate authority about a failure to verify a particular proof of domain ownership. But the error you mentioned in your post describes a reason that Certbot may have crashed. Did these two things happen one after another while you were running Certbot with the command you mentioned? Like you first saw an error message about urn:error:acme:unauthorized and then subsequently saw Certbot crash with the UnicodeEncodeError?
If this is what happened, I think this is a Certbot bug because Certbot should not crash in this particular circumstance. It may be related to the fact that the error message from the CA contained some Cyrillic text in UTF-8 (which the CA received from your server while attempting to download a specific file that Certbot should have placed inside the webroot directory). Maybe we have code in Certbot that gets confused in this circumstance. Could you please clarify a little more about the circumstances?
@ssergio, I’m pretty sure you’ve found a bug in Certbot which is ultimately based on one of the libraries that Certbot uses for communicating with the certificate authority. This library assumes that error messages from the CA will be in ASCII, but the protocol actually allows them to be UTF-8 Unicode. In this case the CA tried to verify a challenge on your server but received a 404 not found error in Russian, which for debugging purposes it then quoted back to Certbot. Certbot then crashed trying to interpret this error because it didn’t expect it to contain Unicode data.
I’ll have to file a bug about this (and thank you for letting us know!). It does appear that the problem is that your server is not serving the correct files at the correct location when attempting to verify the challenge.
You can check whether, for example, creating a file called /projects/project-two.ru/public_html/test.txt results in that file being visible at http://project-two.ru/test.txt (which it should, if the -w was specified correctly). A subsequent test is whether creating a file called /projects/project-two.ru/public_html/.well-known/acme-challenge/test2.txt results in that file being visible at http://project-two.ru/.well-known/acme-challenge/test2.txt.