Failed to obtain certificate acme error 400

(Seunzi Lam) #1

Hi, I am new to caddy and got a question that i can’t find any helpful answer on google, and Thanks for your help!

I am runing flask + gunicorn + caddy(0.11.5) on Ubuntu(18.04.2 LTS)

I followed the document to install and run caddy with Caddyfile(show below) in the first time, it worked perfectly.

#Caddyfile
 jobplus.linxz.rocks {
     root /srv/www/jobplus7-15/
     proxy / unix:/run/gunicorn/socket {
         transparent
     }
     log /var/log/caddy/access.log
     errors /var/log/caddy/errors.log
 }

But when i add one more domian to Caddyfile, it happened with errors.

#Caddyfile
 jobplus.linxz.rocks {
     root /srv/www/jobplus7-15/
     proxy / unix:/run/gunicorn/socket {
         transparent
     }
     log /var/log/caddy/access.log
     errors /var/log/caddy/errors.log
 }

 xinqi.linxz.rocks {
     root /srv/www/Xinqi/
     proxy / unix:/run/gunicorn/xinqi.socket {
         transparent
     }
     log /var/log/caddy/xinqi_access.log
     errors /var/log/caddy/xinqi_errors.log
  }

The logs in systemd:

Mar 28 01:53:37 iZwz9845cet96s964va7u8Z systemd[1]: Started Caddy HTTP/2 web server.
Mar 28 01:53:37 iZwz9845cet96s964va7u8Z caddy[6621]: Activating privacy features... 2019/03/28 01:53:37 [INFO][FileStorage:/etc/ssl/caddy] Started certificate maintenance routine
Mar 28 01:53:37 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:37 [INFO] [xinqi.linxz.rocks] acme: Obtaining bundled SAN certificate
Mar 28 01:53:39 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:39 [INFO] [xinqi.linxz.rocks] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/MpNiTH6EJNZeHmEM-3rpEoJCVKyvvlcNExbz5ZsYOt0
Mar 28 01:53:39 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:39 [INFO] [xinqi.linxz.rocks] acme: use tls-alpn-01 solver
Mar 28 01:53:39 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:39 [INFO] [xinqi.linxz.rocks] acme: Trying to solve TLS-ALPN-01
Mar 28 01:53:40 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:40 http: TLS handshake error from 64.78.149.164:57882: write tcp 172.18.211.158:443->64.78.149.164:57882: write: connection reset by peer
Mar 28 01:53:46 iZwz9845cet96s964va7u8Z caddy[6621]: 2019/03/28 01:53:46 [xinqi.linxz.rocks] failed to obtain certificate: acme: Error -> One or more domains had a problem:
Mar 28 01:53:46 iZwz9845cet96s964va7u8Z caddy[6621]: [xinqi.linxz.rocks] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Connection reset by peer, url:
Mar 28 01:53:46 iZwz9845cet96s964va7u8Z systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Mar 28 01:53:46 iZwz9845cet96s964va7u8Z systemd[1]: caddy.service: Failed with result 'exit-code'.

I have searched about the error message, and sure that 80,443 port are open, no firewall or something blocking, I try runing gunicorn directly to 0.0.0.0:80 or 0.0.0.0:443 and it worked fine.

I tried restart the caddy and using netstat immediately to check the port usage, it seems the caddy only using tcp6 :::443, don’t know if this is the problem.

(Matthew Fay) #2

Hi @Seunzi, welcome to the Caddy community!

This bit is interesting.

If I’m reading this right, both Caddy and LetsEncrypt reported that the connection was reset by peer (the other party!).

The implication, if both sides think the other reset the connection, is that there’s actually a hop between you that’s issuing resets to both sides…

1 Like
(Seunzi Lam) #3

Thank you @Whitestrake .

I tried reinstalling the OS and caddy, it still came out with the same errors.

But then I changed to other VPS which outside the China’s great firewall, it worked fine, I suppose the great firewall is the problem.

Many thanks again for your help!

3 Likes
(Mr Nobody) #4

I came across the same problem and solved also in your way which use a VPS outside GFW. So is there any other solutions?

(Matthew Fay) #5

There’s three points at which this issue could be solved, two of which might be feasible for you.

First, at the issuing end - LetsEncrypt - could probably use a tunnel of some kind. You’ve got no control over LetsEncrypt, though, so this isn’t feasible.

Secondly, the challenge path itself. You likely have no chance of affecting whatever is in the middle, interrupting the process. You can instruct LetsEncrypt to use a challenge that is not vulnerable to this problem. See the DNS challenge: https://caddyserver.com/docs/automatic-https#dns-challenge

Thirdly, the destination. You can control where it is, and putting it outside the GFW appears to solve the issue.