Caddy: v2: file server not serving over tls

Created on 14 Dec 2019 · 2Comments · Source: caddyserver/caddy

1. Environment

1a. Operating system and version

Mac OS inside vmware fusion

$ uname -a
Linux vm 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

1b. Caddy version (run `caddy version` or paste commit SHA)

8005b7ab73c264ee3c1d7b10c39bc5565ef57c02

1c. Go version (if building Caddy from source; run `go version`)

$ go version
go version go1.13.1 linux/amd64

2. Description

2a. What happens (briefly explain what is wrong)

Trying http://localhost:3000 serves the site correctly. When trying https://localhost:3000 I get a few different errors depending on the request.

Certs created with mkcert, showing valid with openssl x509 -in certs/cert.pem -text -noout

curl

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

firefox

An error occurred during a connection to localhost:3000. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

chrome

ERR_SSL_PROTOCOL_ERROR

2b. Why it's a bug (if it's not obvious)

2c. Log output

2019/12/13 23:14:11.609 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
2019/12/13 15:14:11 [INFO][cache:0xc0002dc280] Started certificate maintenance routine
2019/12/13 15:14:11 [WARNING] Stapling OCSP: no OCSP stapling for [localhost]: no OCSP server specified in certificate
2019/12/13 23:14:11.610 INFO    tls     cleaned up storage units
2019/12/13 23:14:11.610 INFO    admin   Caddy 2 serving initial configuration

2d. Workaround(s)

I'd like one 😉

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

Caddyfile

:3000

root * app

# Make HTML file extension optional
try_files {path}.html {path}

# Send requests to /api to backend
reverse_proxy /api localhost:8000

# Serve everything else from the file system
file_server

tls certs/cert.pem certs/key.pem

index.html

<html>
<body>

<h1>Hello World</h1>

</body>
</html>

Create directories

mkdir certs
mkdir app

Create certs

mkcert --install --cert-file certs/cert.pem --key-file certs/key.pem localhost

Create Caddyfile shown above
Create app/index.html
Run (or start) Caddy

caddy run

Navigate to http://localhost:3000 in browser of choice and subsequently https://localhost:3000

If reproduced, you'll see the site load fine over http, but failures over https

bug

Source

zaquestion

Most helpful comment

Thank you for the detailed report!

That made it very easy to find and fix.

mholt on 14 Dec 2019

🎉3

All 2 comments

Thanks for opening an issue! We'll look into this.

It's not immediately clear to me what is going on, so I'll need your help to understand it better.

Ideally, we need to be able to reproduce the bug _in the most minimal way possible_. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! It will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1:

I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

paste here


1b. Caddy version (run caddy version or paste commit SHA)

paste here


1c. Go version (if building Caddy from source; run go version)

paste here


2. Description

2a. What happens (briefly explain what is wrong)

2b. Why it's a bug (if it's not obvious)

2c. Log output

paste terminal output or logs here


2d. Workaround(s)

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

Helpful tips

Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are _always_ relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.
Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.
- 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
- 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
- 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.
Tutorial: What are the _minimum required specific steps_ someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:
- Start with an empty config. Add _only_ the lines/parameters that are _absolutely required_ to reproduce the bug.
- Do not run Caddy inside containers.
- Run Caddy manually in your terminal; do not use systemd or other init systems.
- If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
- Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
- Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file:
{ ... }
Open terminal and run Caddy:
$ caddy ...
Make an HTTP request:
$ curl ...
Notice that the result is ___ but it should be ___.

mholt on 14 Dec 2019

Thank you for the detailed report!

That made it very easy to find and fix.

mholt on 14 Dec 2019

🎉3

Was this page helpful?

0 / 5 - 0 ratings