V2: Automatic HTTPS suddenly broken (still having problems)

1. My Caddy version (caddy C -version):

(devel) [2.0 beta 9]

2. How I run Caddy:

a. System environment:

DigitalOcean VPS running Ubuntu 18.10 with open incoming ports 80 and 443
go version go1.13.4 linux/amd64

b. Command:

bill@Bill2:~/www$ sudo caddy file-server --listen wtrenker.com:443
[sudo] password for bill:
2019/11/15 15:06:31.061 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
2019/11/15 15:06:31 [INFO][cache:0xc0000a5450] Started certificate maintenance routine
2019/11/15 15:06:31.064 INFO    tls     cleaned up storage units
2019/11/15 15:06:31 Caddy 2 serving static files on wtrenker.com:443

c. Service/unit/compose file:

(I’m not sure what exactly to put here.) I am currently starting Caddy manually while I check it out. I am very interested in using Caddy to front-end my small web application with HTTPS. The only thing I’m missing from Caddy is a built-in WSGI interface for back-end access, but I can work around that with some extra programming (in python; I’m at the very beginning of my Go learning curve.)

d. My complete Caddyfile:

I'm not using a Caddyfile yet, this is all simple command-line input.

3. The problem I’m having:

I installed Go and Caddy in test directories 2 days ago and it worked flawlessly. The automatic HTTPS is amazing! Since everything looked good I uninstalled Go and Caddy (deleted their directories) and re-installed them in clean production directories. Since then when I try to access the Caddy file-server I cannot get my web pages, just the security error described below.

So It looks like I have deleted my certificates on the server end by reinstalling Caddy in a new directory. (That’s just a guess but I’m quite sure the problem is my own doing.) If that is the case how do I sort out the certificates?

Also, I’ve tried this out on other clients (Firefox, Edge and Android Chrome on my phone) and I get related errors.

Then, as a stab in the dark, I entered this into my browser: wtrenker.com:443, and to my great surprise, I get my test web pages. although they are not secure (no HTTPS). Something is very strange.

4. Error messages and/or full log output:

On the browser (Chrome Version 78.0.3904.97) I get this message:

This site can’t provide a secure connection

wtrenker.com sent an invalid response.

  • [Try running Windows Network Diagnostics](javascript:diagnoseErrors()).
    ERR_SSL_PROTOCOL_ERROR

(The Windows Network Diagnostics couldn’t identify the problem.)

Here is a log entry when I put wtrenker.com:443 into the browser:

2019/11/15 16:19:19.002 INFO    http.log.access handled request {"request": {"method": "GET", "uri": "/", "proto": "HTTP/1.1", "remote_addr": "23.16.240.22:49474", "host": "wtrenker.com:443", "headers": {"Upgrade-Insecure-Requests": ["1"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"], "Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate"], "Connection": ["keep-alive"]}}, "common_log": "23.16.240.22 - - [15/Nov/2019:16:19:19 +0000] \"GET / HTTP/1.1\" 200 122", "latency": 0.000120121, "size": 122, "status": 200, "resp_headers": {"Etag": ["\"q0z1xo3e\""], "Content-Type": ["text/html; charset=utf-8"], "Last-Modified": ["Thu, 14 Nov 2019 18:27:24 GMT"], "Accept-Ranges": ["bytes"], "Content-Length": ["122"], "Server": ["Caddy"]}}

5. What I already tried:

I have rebooted the client machine, a Windows laptop also running ssh access to the VPS. And I have rebooted the VPS, several times. I have made sure there are no other processes on the VPS that are listening on ports 80 and 443.

6. Links to relevant resources:

I have done quite a bit of research on Google and I have looked through this forum. I have found some related info but nothing that steers me in the right direction.

Thanks in advance for any help you can provide. Bill

Thanks for trying v2 while it’s still in beta!

I think you want --domain instead of --listen.

$ caddy file-server --domain wtrenker.com

And it should do the rest for you.

Using --listen is solely for the socket interface.

Docs are here: GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

--listen accepts a listener address; the default is :2015 . If --domain is specified, then the files will only be served from that domain name, and Caddy will attempt to serve it over HTTPS if it qualifies for a certificate, so make sure your DNS is configured properly.

Any suggestions on how we could improve/clarify this?

(Also, super thank you for not redacting your domain name, made this real easy to figure out what was going on. /cc @whitestrake – great example here)

PS. You don’t need Go installed to run Caddy.

1 Like

Hello and thank you for taking the time for a great response.

I restarted Caddy as shown here:

bill@Bill2:~/www$ sudo caddy file-server --domain wtrenker.com
2019/11/16 01:55:53.458 INFO admin admin endpoint started {“address”: “localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”]}
2019/11/16 01:55:53.459 INFO http enabling automatic TLS certificate management {“domains”: [“wtrenker.com”]}
2019/11/16 01:55:53.460 INFO http enabling automatic HTTP->HTTPS redirects {“domains”: [“wtrenker.com”]}
2019/11/16 01:55:53.461 INFO tls cleaned up storage units
2019/11/16 01:55:53 [INFO][cache:0xc0000a54a0] Started certificate maintenance routine
2019/11/16 01:55:53 Caddy 2 serving static files on :2015

Notice in the last line that Caddy is serving on :2015.

When I put wtrenker.com in the browser’s address box I get a long pause and then the error message:

This site can’t be reached

wtrenker.com took too long to respond.
Try:

The address box has also changed to show https://wtrenker.com:2015/

In your command line example, you don’t use sudo. I have to use sudo (see above) or Caddy fails on the following error:

file-server: loading new config: http app module: start: tcp: listening on :80: listen tcp :80: bind: permission denied

Thanks again for taking the time to point out my error, Bill.

1 Like

Oops, that’s a bug. If you specify a domain name it should use the standard HTTPS port. Will fix it later. (or accept a PR for it)

In the meantime, you can use --listen :443 to set the port to 443.

(And yes, you need permissions to bind to lower ports; I’m trying not to make any assumptions here, so don’t take what I say literally, you’ll have to adapt it to your specific setup)

1 Like

@William_Trenker Got that fixed in file_server: Use HTTPS port when a qualifying domain is specified · caddyserver/caddy@9fe54e1 · GitHub

If you pull the latest on the v2 branch and try again, it should serve on the 443 port.

Or wait for beta 10, which I hope will go out Monday.

Your last advice solved my problem. The main point is that I need to give the domain name for the automatic HTTPS to work. And for now, I have to specify the port (443). A simple example is:

sudo caddy file-server --listen :443 --domain wtrenker.com

And it works just great!

Thanks very much for your help. -Bill

PS: I want to edit the title of this post (to mark it as solved) but the edit icon is not showing next to the title.

1 Like

Great, thanks for letting me know! Glad it is working now.

The best way to do this is to select the check box icon next to the post that answers your question – it might be hidden under the “…” button. I did it for you in this case.

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