[solved] Location block problem for acme-challenge

[andymel]

Hi,

I have installed certbot and my first certificates like described here.
I also did a renew crontab but I have the following error:
Attempting to renew cert from /etc/letsencrypt/renewal/XX.com.conf produced an unexpected error: ‘ascii’ codec can’t encode character u’\ufeff’ in position 193: ordinal not in range(128). Skipping.
My certificate expires tomorrow.

I guess I already know what the problem is: My nginx config for that domain redirects everything to https / index.php.
I added the following location block to not redirect the acme-challenge but it seems like I do it wrong.

server {

        listen 80 default_server;
        listen [::]:80 default_server;

        server_name XX.com *.XX.com;

        location ^~ /.well-known/acme-challenge/ {

            default_type "text/plain";

            root /var/www/html/XX.com/;
        }

        return 301 https://$server_name$request_uri;
}

The root path is the same as in the conf file of the /etc/letsencrypt/renew directory.
I also tried
root /var/www/html/XX.com;
and
root /var/www/html/XX.com/.well-known/acme-challenge/;

Both are also not working.

[jmorahan]

@andymel

I guess I already know what the problem is: My nginx config for that domain redirects everything to https / index.php.

That could be a problem, but it's not what certbot is complaining about, and your location block looks correct to me (though I'm not am nginx expert).

Could you share the full contents of the file /etc/letsencrypt/renewal/XX.com.conf? If at all possible please do not redact your domain name as there's a good chance the name itself is part of the problem here. Also what version of certbot are you using?

[andymel]

Hi @jmorahan,

ok here is the content of /etc/letsencrypt/renewal/amcoustics.com.conf

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/amcoustics.com
cert = /etc/letsencrypt/live/amcoustics.com/cert.pem
privkey = /etc/letsencrypt/live/amcoustics.com/privkey.pem
chain = /etc/letsencrypt/live/amcoustics.com/chain.pem
fullchain = /etc/letsencrypt/live/amcoustics.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = f348847389104513e9a7535ff47f8d45
[[webroot_map]]
amcoustics.com = /var/www/html/amcoustics.com

My first attempt was to look at that file with xxd /etc/letsencrypt/renewal/amcoustics.com.conf to see the hex content. But there seems to be no character feff used. But maybe I misunderstand what it means.

Regarding the location block: I tried to set a test file and retrieve it with curl…but without luck…so the location block really seems to be not working.

I’m using certbot 0.10.2 (seems to be the newest version of debian 8)

[jmorahan]

Ah, hmm.

On closer inspection, that error looks like it might be related to certbot trying to parse a UTF-16 encoded file. Did you edit any files locally, especially in Windows, and upload them? If so, double check that they are UTF-8 encoded.

[mnordhoff]

@andymel

    location ^~ /.well-known/acme-challenge/ {

        default_type "text/plain";

        root /var/www/html/XX.com/;
    }

    return 301 https://$server_name$request_uri;

You need to put the return directive inside "location / { ... }".

Edit: But it's true that the redirect is probably orthogonal to the character issue.

[Patches]

Can you paste the contents of /var/log/letsencrypt/letsencrypt.log?

The problem is probably not with the renewal file, but with some other file certbot needs to read pertaining to that domain. The debug log would tell us which one it is.

[andymel]

@mnordhoff

You need to put the return directive inside “location / { ... }”.

Thanks a lot @mnordhoff!! This was the missing part! I didn't know that the return statement needs its own location block. As that redirect did work I never would have spotted this as the problem without your help!

@mnordhoff

Edit: But it’s true that the redirect is probably orthogonal to the character issue.

The character issue is gone now. Seems like it really was a follow up problem reading the (wrong) result of the challenge request.

@Patches

Can you paste the contents of /var/log/letsencrypt/letsencrypt.log?

Thanks to the log I had the idea with the not working redirect. From the log:

 "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:unauthorized",
        "detail": "Invalid response from http://amcoustics.com/.well-known/acme-challenge/wGHKtjpRsBolNhj7RSAZh6Uk0VmPb_XHs5OaDyoAgZs: \" \u003c!doctype html\u003e\n\u003chtml lang=\"en\"\u003e\n\u003chead\u003e\n\u003cmeta charset=\"ut$
        "status": 403
      },

My certificate is new again some hours before expiration...I can sleep now
A big THANK YOU to @Patches and @jmorahan as well!!