Port and certificate errors with https file-server on localhost

1. Caddy version (caddy version):

v2.0.0 installed via sudo apt install caddy

2. How I run Caddy:

a. System environment:

Ubuntu 20.04 desktop amd64

b. Command:

caddy file-server --domain localhost

and

caddy file-server --domain localhost --listen :8082

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

N/A using CLI

3. The problem I’m having:

I am failing to get caddy to run because of port binding permissions (initially for 80/443) so I tried using a high port but I guess I am trying to set the port wrong because the log implies my port choice is ignored.

4. Error messages and/or full log output:

With:

caddy file-server --domain localhost

I get the below:

2020/05/19 12:28:15.087	WARN	admin	admin endpoint disabled
2020/05/19 12:28:15.087	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "static", "https_port": 443}
2020/05/19 12:28:15.088	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "static"}
2020/05/19 13:28:15 [INFO][cache:0xc00027c730] Started certificate maintenance routine
2020/05/19 12:28:15.117	INFO	tls	setting internal issuer for automation policy that has only internal subjects but no issuer configured	{"subjects": ["localhost"]}
2020/05/19 12:28:15.118	INFO	tls	cleaned up storage units
2020/05/19 12:28:15.188	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
file-server: loading new config: http app module: start: tcp: listening on :443: listen tcp :443: bind: permission denied

So I tried to use a custom high port:

caddy file-server --domain localhost --listen :8082

This gives the error:

2020/05/19 12:28:15.087	WARN	admin	admin endpoint disabled
2020/05/19 12:28:15.087	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "static", "https_port": 443}
2020/05/19 12:28:15.088	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "static"}
2020/05/19 13:28:15 [INFO][cache:0xc00027c730] Started certificate maintenance routine
2020/05/19 12:28:15.117	INFO	tls	setting internal issuer for automation policy that has only internal subjects but no issuer configured	{"subjects": ["localhost"]}
2020/05/19 12:28:15.118	INFO	tls	cleaned up storage units
2020/05/19 12:28:15.188	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
file-server: loading new config: http app module: start: tcp: listening on :443: listen tcp :443: bind: permission denied

5. What I already tried:

I’ve tried without --domain localhost and that serves it over http with no redirect to https - I think I expect that to be the case.
I’ve also tried running with a caddyfile

localhost:8082

bind 127.0.0.1
root * Dist/web
file_server

and caddy start but I get a different error:

2020/05/19 12:52:22.939	INFO	using adjacent Caddyfile
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use
start: caddy process exited with error: exit status 1

I also tried adding

http_port   8081
https_port  8082

but I think I was setting up the caddyfile wrong because I couldn’t get that to work either.
Caddyfile:3: unrecognized directive: http_port

6. Links to relevant resources:

N/A


I hope that there is something simple and blindingly obvious that I’m missing!

To disable HTTPS, prepend http:// to the address.

In the Caddyfile, global options must be in a block, as the first thing at the top, like this:

{
    http_port 8081
    https_port 8082
}

<the rest of your Caddyfile>

The error about localhost:2019 is likely because you already have another instance of Caddy running (i.e. the systemd service). Caddy listens on port 2019 for the admin API (which is also used for triggering graceful config reloads).

1 Like

Perfect, it was running as a service so

sudo systemctl disable caddy

and then getting the ports correctly in the caddyfile as you suggested did the trick.

Thank you so much for your help. :slightly_smiling_face:

1 Like

I’ve just realised that a though my original issue is now resolved, and I am getting my localhost files over https on port 8082 (what I wanted), I now have the browsers (Firefox and Chromium) both reporting that the certificate isn’t trusted:

caddy run:

2020/05/19 17:20:49.075	INFO	using adjacent Caddyfile
2020/05/19 17:20:49.077	INFO	admin	admin endpoint started	{"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2020/05/19 17:20:49.077	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "srv0", "https_port": 8082}
2020/05/19 17:20:49.077	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2020/05/19 18:20:49 [INFO][cache:0xc000029d60] Started certificate maintenance routine
2020/05/19 17:20:49.092	INFO	tls	setting internal issuer for automation policy that has only internal subjects but no issuer configured	{"subjects": ["localhost"]}
2020/05/19 17:20:49.093	INFO	tls	cleaned up storage units
2020/05/19 17:20:49.157	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
2020/05/19 17:20:49.158	INFO	http	enabling automatic TLS certificate management	{"domains": ["localhost"]}
2020/05/19 18:20:49 [WARNING] Stapling OCSP: no OCSP stapling for [localhost]: no OCSP server specified in certificate
2020/05/19 17:20:49.158	INFO	autosaved config	{"file": "/home/stuart/.config/caddy/autosave.json"}
2020/05/19 17:20:49.159	INFO	serving initial configuration

Chromium:

NET::ERR_CERT_AUTHORITY_INVALID
Subject:

Issuer: Caddy Local Authority - ECC Intermediate

Expires on: 20 May 2020

Current date: 19 May 2020
............
............
This server could not prove that it is localhost; its security certificate is not trusted by your computer's operating system.

Caddys log then reports:

2020/05/19 18:52:37 http: TLS handshake error from [::1]:36356: remote error: tls: unknown certificate

Am I understanding wrong? I thought that according to this Automatic HTTPS — Caddy Documentation caddy would install a locally trusted CA meaning the browsers would be happy with the certificates?

The root CA installation is best-effort, it might not always work depending on if your browser isn’t detected by the script and whatnot. Firefox bundles its own CA store, it doesn’t use the system one. Chromium as far as I know should use the system CA store. Did you run the caddy trust command? That may or may not fix things.

IIRC Firefox also requires restarting before it picks up any trust store changes. And the auto-trust won’t work for Firefox on Windows.

I’m not having much luck.

I tried caddy trust and restarting Firefox/chromium and even the ubuntu OS but nothing made a difference.

So, I built a fresh Ubuntu 20.04 virtual machine and started again. This time I rebooted the OS between each of steps below:

  1. Install Ubuntu
  2. sudo apt install libnss3-tools
  3. downloaded the v2 caddy binary
  4. Installed chromium and opened it / opened Firefox
  5. ./caddy trust (and gave it my password at the prompt)
2020/05/20 10:24:37.512	WARN	ca.local	installing root certificate (you might be prompted for password)	{"path": "storage:pki/authorities/local/root.crt"}
2020/05/20 11:24:37 certificate installed properly in NSS security databases
2020/05/20 11:24:37 define JAVA_HOME environment variable to use the Java trust
[sudo] password for stuart: 
2020/05/20 11:24:54 certificate installed properly in linux trusts
  1. Opened and closed Firefox and Chromium
  2. ./caddy run
2020/05/20 10:37:24.512	INFO	using adjacent Caddyfile
2020/05/20 10:37:24.518	INFO	admin	admin endpoint started	{"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2020/05/20 10:37:24.519	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "srv0", "https_port": 8082}
2020/05/20 10:37:24.519	INFO	http	enabling automatic HTTP->HTTPS redirects{"server_name": "srv0"}
2020/05/20 11:37:24 [INFO][cache:0xc000475d10] Started certificate maintenance routine
2020/05/20 10:37:24.531	INFO	tls	setting internal issuer for automation policy that has only internal subjects but no issuer configured	{"subjects": ["localhost"]}
2020/05/20 10:37:24.533	INFO	tls	cleaned up storage units
2020/05/20 10:37:24.590	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
2020/05/20 10:37:24.591	INFO	http	enabling automatic TLS certificate management	{"domains": ["localhost"]}
2020/05/20 10:37:24.593	INFO	autosaved config	{"file": "/home/stuart/.config/caddy/autosave.json"}
2020/05/20 10:37:24.593	INFO	serving initial configuration
2020/05/20 11:37:24 [INFO][localhost] Obtain certificate; acquiring lock...
2020/05/20 11:37:24 [INFO][localhost] Obtain: Lock acquired; proceeding...
2020/05/20 11:37:24 [INFO][localhost] Certificate obtained successfully
2020/05/20 11:37:24 [INFO][localhost] Obtain: Releasing lock
2020/05/20 11:37:24 [WARNING] Stapling OCSP: no OCSP stapling for [localhost]: no OCSP server specified in certificate
  1. Opened Chromium and browsed to my site - got a certificate error and caddy log reflects this
2020/05/20 11:40:24 http: TLS handshake error from [::1]:43398: remote error: tls: unknown certificate
2020/05/20 11:40:24 http: TLS handshake error from [::1]:43400: remote error: tls: unknown certificate

I even ran untrust and then trust and run with sudo but it made no difference.

Once it is trusted by the system it won’t try to continue installing it. At this point either uninstall from the system and try again, or install it manually into Firefox are my two suggestions.

Thanks Matt. So are you thinking that by the time I used sudo it was too late as it was already installed? What is the uninstall procedure so that I can try again, I thought caddy untrust effectively uninstalled it?

Did untrust succeed?

I honestly don’t know what is happening, I would just install it manually if you’re having problems.

I don’t know how to see if untrust does all it should, I get this:

2020/05/20 16:35:54 not NSS security databases found
2020/05/20 16:35:54 define JAVA_HOME environment variable to use the Java trust
2020/05/20 16:35:55 certificate uninstalled properly from linux trusts

So, once I do that, when you suggest I install it manually, I’m not sure what you mean/how to do that. Are you able to point me towards some instructions please?

Just googling a few links:

Caddy’s root cert file path is printed in the log entries.

Thanks, I see what you mean by installing it manually. Just to be clear, my issue is not really with Firefox I have been testing primarily with Chromium (as well as checking with Firefox).

I was hoping to use caddy as a better alternative to running https://mkcert.dev/ as caddy provisions, renews and serves files. I was also going to see if it could help with grpc-web communications on localhost.

Is this the first time you have seen it not work? Is there something I can do to help you troubleshoot it? Caddy is an amazing project (thank you :star_struck:) and I suspect I won’t be the only one hoping to use it this way.

Caddy uses GitHub - smallstep/truststore: Package to locally install development certificates which does the same thing as mkcert. If it fails with Caddy, it’ll probably also fail with mkcert, I think. :man_shrugging:

Caddy actually uses mkcert under the hood (well, a fork of it that makes it a little easier for library use, but same internal guts). You could check their issue tracker to see if anyone has had similar problems.

Yeah, I think this is the first issue with this feature where at a glance I don’t know what’s wrong. Caddy 2 is only a couple weeks old. The few questions in the past have been answered with things like “this feature doesn’t work for BSD” or “it doesn’t support Firefox on Windows” but Firefox on Ubuntu works for me (and most others), so… :man_shrugging:

This’ll be improved in the future, as there’s rumors of a Go trust store API being developed…

Thanks for your thoughts, I can’t see anything in the mkcert issue tracker and I tried mkcert on my Ubuntu 20.04 vm and the mkcert certificates did work (they were trusted by the browsers).

To try and narrow it down:

  • I tested with an Ubuntu 16.04 vm I had, it worked absolutely fine.
  • I tested with an Ubuntu 18.04 vm I had, it worked absolutely fine.
  • I tested with a Windows 10 vm, it worked absolutely fine.
  • I tested on OSX 10.15.4 too, again it worked fine.

I hadn’t considered how recent Ubuntu 20.04 is but given I have reinstalled the OS from scratch twice to test this, I think it seems that this feature doesn’t work/hasn’t yet been tested in Ubuntu 20.04 as it does on earlier versions & OSs.
Can anyone confirm this and would you like a GitHub issue raised?

That’s some deep investigation work, thank you! I don’t have Ubuntu handy so I can’t test it right now, but if you would be able to look into the code as to why it’s not working, that would be the fastest way to a solution. :+1: I would appreciate that a lot, as would other Ubuntu users probably.

I’ll add having a look at this to our team’s to do list but we are very busy with our project and I’m not sure when we will get to have a look.

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