Can't generate certificate


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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot certonly --webroot -w /abc/def/images -d --server

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /abc/def/images for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Could not communicate with VA


  • The following errors were reported by the server:

    Type: serverInternal
    Detail: Could not communicate with VA

    Unfortunately, an error on the ACME server prevented you from
    completing authorization. Please try again later.

My web server is (include version): nginx/1.15.3

The operating system my web server runs on is (include version):
Centos 7 (Linux 3.10.0-862.3.2.el7.x86_64 x86_64)

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

This problem just occurred recently this use to work just fine. It started when the certificates need to be renewal but this time this error pops up and no matter what I tried I can’t create a certificate on this subdomain. So I decided to delete the cert and generate a new one, but the same error pops up again. I have another subdomain on this server as well, but that one works perfectly fine. Right now I am using a wild-domain cert on this domain name while I am trying to fix this issue.


The error appears to be outbound from your server; as it is unable to communicate with the Validation Authority.
Have you changed your outbound firewall policy since your last renewal?
Please test your servers connectivity to:

OR is isn’t your fault at all:


To my knowledge I didn’t touch this server firewall config for a long time. I don’t think the firewall is the issue. I just created another subdomain and try generate a cert on that one and it was a success. I think this might be NGINX configuration issue, permission issue or something else.


Can you make a test page on ?

I think you might be crashing the Let’s Encrypt validation service with your server’s response :stuck_out_tongue: .

If you can show your nginx virtual host configuration, perhaps we can check why all responses appear to be a gif rather than being served from your document root.


So yeah, I think this is a Let’s Encrypt-side crash of sorts. The RPC transport that Let’s Encrypt use appears to be choking on one of the messages being sent (presumably the first x bytes of your server’s HTTP response to be reported back to the WFE for the “unauthorized” message) due to the binary data in the response.

This can be reproduced by running it from source:

I074024 boulder-va [AUDIT] Attempting to validate http-01 for
I074025 boulder-va [AUDIT] Checked CAA records for, [Present: false, Account ID: 3, Challenge: http-01, Valid for issuance: true] Records=null
I074027 boulder-va The key authorization file from the server did not match this challenge [suPUjBcpGo-6haldYaETbi3paa62mQF-d4TQVV5QfVc.QUUqmF41OKBr3xbIxT2s-CCoLnGOIL0VsEUczR5Ry5A] != [GIF89a����!�,L;] for {dns}
I074027 boulder-va [AUDIT] Validation result JSON={"ID":"BMfatXsDhT2QxKMGGVf2e2N2-0SxbufmoatXMwGWr00","Requester":3,"Hostname":"","ValidationRecords":[{"url":"","hostname":"","port":"80","addressesResolved":[""],"addressUsed":""},{"url":"","hostname":"","port":"443","addressesResolved":[""],"addressUsed":""}],"Challenge":{"id":6,"type":"http-01","status":"invalid","error":{"type":"unauthorized","detail":"The key authorization file from the server did not match this challenge [suPUjBcpGo-6haldYaETbi3paa62mQF-d4TQVV5QfVc.QUUqmF41OKBr3xbIxT2s-CCoLnGOIL0VsEUczR5Ry5A] != [GIF89a\u0001\u0000\u0001\u0000\ufffd\u0001\u0000\u0000\u0000\u0000\ufffd\ufffd\ufffd!\ufffd\u0004\u0001\u0000\u0000\u0001\u0000,\u0000\u0000\u0000\u0000\u0001\u0000\u0001\u0000\u0000\u0002\u0002L\u0001\u0000;]","status":403},"token":"suPUjBcpGo-6haldYaETbi3paa62mQF-d4TQVV5QfVc","keyAuthorization":"suPUjBcpGo-6haldYaETbi3paa62mQF-d4TQVV5QfVc.QUUqmF41OKBr3xbIxT2s-CCoLnGOIL0VsEUczR5Ry5A","validationRecord":[{"url":"","hostname":"","port":"80","addressesResolved":[""],"addressUsed":""},{"url":"","hostname":"","port":"443","addressesResolved":[""],"addressUsed":""}]},"RequestTime":"2018-09-19T07:40:24.749779759Z","ResponseTime":"0001-01-01T00:00:00Z","Error":"unauthorized :: The key authorization file from the server did not match this challenge [suPUjBcpGo-6haldYaETbi3paa62mQF-d4TQVV5QfVc.QUUqmF41OKBr3xbIxT2s-CCoLnGOIL0VsEUczR5Ry5A] != [GIF89a\u0001\u0000\u0001\u0000\ufffd\u0001\u0000\u0000\u0000\u0000\ufffd\ufffd\ufffd!\ufffd\u0004\u0001\u0000\u0000\u0001\u0000,\u0000\u0000\u0000\u0000\u0001\u0000\u0001\u0000\u0000\u0002\u0002L\u0001\u0000;]"}
I074027 boulder-va Validations: {ID:BMfatXsDhT2QxKMGGVf2e2N2-0SxbufmoatXMwGWr00 Identifier:{Type: Value:} RegistrationID:3 Status: Expires:<nil> Challenges:[] Combinations:[] Wildcard:false}
E074027 boulder-va [AUDIT] grpc: server failed to encode response:  rpc error: code = Internal desc = grpc: error while marshaling: proto: invalid UTF-8 string

E074027 boulder-ra [AUDIT] Could not communicate with VA: rpc error: code = Internal desc = grpc: error while marshaling: proto: invalid UTF-8 string

Luckily for you, you can fix it by configuring nginx to serve the challenge response correctly instead of this gif.

Edit: Looks like this is already fixed - - but by the looks of it, not deployed yet.


Hi @Solu

your /.well-known/acme-challenge/ - subdirectory shouldn’t send image/gif - content.

download -h
Connection: keep-alive
Keep-Alive: timeout=30
Pragma: public
Content-Length: 43
Cache-Control: max-age=15552000,public
Content-Type: image/gif
Date: Wed, 19 Sep 2018 07:41:41 GMT
Expires: Mon, 18 Mar 2019 07:41:41 GMT
Last-Modified: Mon, 28 Sep 1970 06:00:00 GMT
Server: nginx

Status: 200 OK

This is really a NGINX configuration issue.


Just like @JuergenAuer and @_az pointed out adding this NGINX block solved the problem

location /.well-known/acme-challenge {
root /abc/def/images;

Thank you very much for your help! :slight_smile:


That’s correct. This will go out in Thursday’s release.


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