Caddy: v2: tls wrong load_files sub-directive at Caddyfile conversion and unexpected automatic HTTPS for second domain in same server block
1. Which version of Caddy are you using (caddy -version)?
Caddy v2, built including ed40a5d
2. What are you trying to do?
Run Caddy v2 with two domains and automatic HTTPS.
3. What is your Caddyfile?
{
handler_order appearance
experimental_http3
}
domain.com, www.domain.com
root * /var/www/html
tls /path/to/certfile.crt /path/to/keyfile.key
encode {
brotli
zstd
gzip
}
php_fastcgi unix//run/php/php7.3-fpm.sock
file_server
Converted file:
{
"apps": {
"http": {
"servers": {
"srv0": {
"listen": [
":443"
],
"routes": [
{
"match": [
{
"host": [
"domain.com",
"www.domain.com"
]
}
],
"handle": [
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"handler": "vars",
"root": "/var/www/html"
},
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"encodings": {
"brotli": {},
"gzip": {},
"zstd": {}
},
"handler": "encode"
}
]
},
{
"handle": [
{
"handler": "rewrite",
"rehandle": true,
"uri": "{http.matchers.file.relative}{http.request.uri.query_string}"
}
],
"match": [
{
"file": {
"try_files": [
"{http.request.uri.path}",
"index.php"
]
}
}
]
},
{
"handle": [
{
"handler": "reverse_proxy",
"transport": {
"protocol": "fastcgi",
"split_path": ".php"
},
"upstreams": [
{
"dial": "unix//run/php/php7.3-fpm.sock"
}
]
}
],
"match": [
{
"path": [
"*.php"
]
}
]
},
{
"handle": [
{
"handler": "file_server",
"hide": [
"Caddyfile"
]
}
]
}
]
}
]
}
]
}
]
}
],
"experimental_http3": true
}
}
},
"tls": {
"certificates": {
"tls.certificates.load_files": [
{
"certificate": "/path/to/certfile.crt",
"key": "/path/to/keyfile.key"
}
]
},
"automation": {},
"session_tickets": {}
}
}
}
4. How did you run Caddy (give the full command and describe the execution environment)?
$ ./caddy run -config=/path/to/Caddyfile
5. Please paste any relevant HTTP request(s) here.
None
6. What did you expect to see?
Caddy v2 starting and running with the converted json Caddyfile.
7. What did you see instead (give full error messages and/or log)?
```$ ./caddy run -config=/path/to/Caddyfile
2019/09/13 11:14:22 Caddy 2 admin endpoint listening on localhost:2019
2019/09/13 11:14:22 starting caddy administration endpoint: loading initial config: running: loading app module 'tls': provision tls: loading certificate module 'tls.certificates.load_files': unknown module: tls.certificates.tls.certificates.load_files
If I change this line from converted Caddyfile:
"tls.certificates.load_files":
into:
"load_files":
Caddy v2 does start, **BUT** it then tries to obtain a certificate for my second domain name: _www.domain.com_, whereas for _domain.com_ it uses the path of cert and key provided in the config as you can see here:
$ ./caddy run -config=/path/to/Caddyfile
2019/09/13 11:16:16 Caddy 2 admin endpoint listening on localhost:2019
2019/09/13 11:16:16 [INFO][cache:0xc000152cd0] Started certificate maintenance routine
2019/09/13 11:16:16 [INFO][domain.com] Skipping automatic certificate management because a certificate with that SAN is already loaded
2019/09/13 11:16:16 [INFO] Enabling automatic HTTPS certificates for [www.domain.com]
2019/09/13 11:16:17 [INFO][www.domain.com] Obtain certificate
2019/09/13 11:16:17 [INFO][FileStorage:/root/.local/share/caddy] Lock for 'cert_acme_www.domain.com_https://acme-v02.api.letsencrypt.org/directory' is stale; removing then retrying: /root/.local/share/caddy/locks/cert_acme_www.domain.com_httpsacme-v02.api.letsencrypt.orgdirectory.lock
2019/09/13 11:16:17 [INFO] [www.domain.com] acme: Obtaining bundled SAN certificate
2019/09/13 11:16:18 [INFO] [www.domain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/306358072
2019/09/13 11:16:18 [INFO] [www.domain.com] acme: Could not find solver for: tls-alpn-01
2019/09/13 11:16:18 [INFO] [www.domain.com] acme: use http-01 solver
2019/09/13 11:16:18 [INFO] [www.domain.com] acme: Trying to solve HTTP-01
^C2019/09/13 11:16:19 [INFO] SIGINT: Shutting down
^C2019/09/13 11:16:21 [INFO] SIGINT: Force quit
```
It should be noted that the loaded cert and key files are my wildcard certificate (e.g _*.domain.com_).
8. Why is this a bug, and how do you think this should be fixed?
Caddy v2 Caddyfile converter might mistakenly convert the load_files subdirectory into above stated string, which is not correct, and when correcting it manually, it tries to obtain a second certificate for my second domain _www.domain.com_.
9. What are you doing to work around the problem in the meantime?
Seperate both domains in two different server blocks, but this is nasty and makes the json config very large.
10. Please link to any related issues, pull requests, and/or discussion.
None that I've discovered so far.
Bonus: What do you use Caddy for? Why did you choose Caddy?
Private projects and webapps :-)
Henrocker
All 5 comments
@Henrocker Thanks for the report. I found the bug causing the name "tls.certificates.load_files" to be used instead of "load_files", and I got that fixed locally; am now looking into your second issue.
Is there any particular reason you've redacted the domain names? I need to know the exact names being used to debug this further.
Also, what are the full and exact names on the certificate (SANs)?
mholt
on 13 Sep 2019
Here is my complete unredacted v2 Caddyfile:
Caddyfile
{
handler_order appearance
experimental_http3
}
hnrk.io, www.hnrk.io
root * /etc/caddy/html
tls /etc/caddy/hnrk.io.crt /etc/caddy/hnrk.io.key
encode {
brotli
zstd
gzip
}
php_fastcgi unix//run/php/php7.3-fpm.sock
file_server
And here is my converted one:
JSON Caddyfile
{
"apps": {
"http": {
"servers": {
"srv0": {
"listen": [
":443"
],
"routes": [
{
"match": [
{
"host": [
"hnrk.io",
"www.hnrk.io"
]
}
],
"handle": [
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"handler": "vars",
"root": "/etc/caddy/html"
},
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"encodings": {
"brotli": {},
"gzip": {},
"zstd": {}
},
"handler": "encode"
}
]
},
{
"handle": [
{
"handler": "rewrite",
"rehandle": true,
"uri": "{http.matchers.file.relative}{http.request.uri.query_string}"
}
],
"match": [
{
"file": {
"try_files": [
"{http.request.uri.path}",
"index.php"
]
}
}
]
},
{
"handle": [
{
"handler": "reverse_proxy",
"transport": {
"protocol": "fastcgi",
"split_path": ".php"
},
"upstreams": [
{
"dial": "unix//run/php/php7.3-fpm.sock"
}
]
}
],
"match": [
{
"path": [
"*.php"
]
}
]
},
{
"handle": [
{
"handler": "file_server",
"hide": [
"Caddyfile"
]
}
]
}
]
}
]
}
]
}
]
}
],
"experimental_http3": true
}
}
},
"tls": {
"certificates": {
"load_files": [
{
"certificate": "/etc/caddy/hnrk.io.crt",
"key": "/etc/caddy/hnrk.io.key"
}
]
},
"automation": {},
"session_tickets": {}
}
}
}
And the certificate:
Henrocker
on 13 Sep 2019
@Henrocker Excellent, thank you! That made this way easier. I've just pushed a hopeful fix. Can you try the latest on the v2 branch and let me know how it goes?
mholt
on 13 Sep 2019
@mholt YAY! It works :-) Though in line _2019/09/13 20:36:00 [INFO] Enabling automatic HTTPS certificates for []_, the domain names are omitted.
$ ./caddy run -config=/etc/v2caddy/Caddyfile
2019/09/13 20:36:00 Caddy 2 admin endpoint listening on localhost:2019
2019/09/13 20:36:00 [INFO][cache:0xc000135400] Started certificate maintenance routine
2019/09/13 20:36:00 [INFO][hnrk.io] Skipping automatic certificate management because one or more matching certificates are already loaded
2019/09/13 20:36:00 [INFO][www.hnrk.io] Skipping automatic certificate management because one or more matching certificates are already loaded
2019/09/13 20:36:00 [INFO] Enabling automatic HTTPS certificates for []
2019/09/13 20:36:00 [INFO] Enabling automatic HTTP->HTTPS redirects for [hnrk.io www.hnrk.io]
2019/09/13 20:36:00 [INFO] Enabling experimental HTTP/3 listener on :443
2019/09/13 20:36:00 Caddy 2 serving initial configuration
Thank you for your very fast fixing! Now if basicauth finds its way into Caddy v2, I'm can safely say I'm going to switch completely to v2!
Henrocker
on 13 Sep 2019
That's great to hear. :)
The list is empty because all the domains that would have had managed certificates don't, because the certificates are now loaded manually.
For future reference, fix was in commit 839507e24e4d8d2d8052335fafb110513865efc0.
It seems to be working as expected, so I will close this. Thanks! Stay tuned for a beta release today.
mholt
on 13 Sep 2019
Related issues
kilpatty
路
3Comments
billop
路
3Comments
xfzka
路
3Comments
lorddaedra
路
3Comments
klaasel
路
3Comments