1. My Caddy version (caddy version):
v2.0.0-beta.17 h1:x+Ur3uX83j+STerOWsrLDlknXe7z71VnO5xD+H2OwAw=
( downloaded off of github releases )
2. How I run Caddy:
plain binary execution since this is a test server and I can SSH into the machine
a. System environment:
lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
b. Command:
sudo caddy run --config config.caddy.json ( I run with sudo so that caddy can access /etc/letsencrypt/live )
d. My complete Caddyfile or JSON config:
{
"apps" : {
"http" : {
"servers" : {
"caddy.test.shinenelson.xyz" : {
"listen" : [
":80",
":443"
],
"automatic_https" : {
"disable" : true,
"disable_redirects" : true
},
"routes" : [
{
"match" : [
{
"host" : [
"*.shine.caddy.test.shinenelson.xyz"
]
}
],
"handle": [
{
"handler": "static_response",
"body": "Hi there, love from shine and Caddy!"
}
],
"terminal" : true
}
],
"tls_connection_policies" : [
{
"match" : {
"sni" : [
"shine.caddy.test.shinenelson.xyz",
"shine.shine.caddy.test.shinenelson.xyz",
"something.shine.caddy.test.shinenelson.xyz",
"*.shine.caddy.test.shinenelson.xyz"
]
},
"certificate_selection" : {
"policy" : "custom",
"tag" : "shine"
}
}
]
}
}
},
"tls" : {
"certificates" : {
"load_files" : [
{
"certificate" : "/etc/letsencrypt/live/caddy.test.shinenelson.xyz/fullchain.pem",
"key" : "/etc/letsencrypt/live/caddy.test.shinenelson.xyz/privkey.pem",
"tags" : [ "caddy", "test", "shine" ]
}
]
}
}
}
}
3. The problem I’m having:
I have one wildcard TLS certificate covering the SNIs - caddy.test.shinenelson.xyz and *.shine.caddy.test.shinenelson.xyz from the staging endpoint of Let’s Encrypt ACME ( this is only a test server ( notice the test subdomain ) that I’ll pull down every now and then ).
The certificate works if I use subdomains that are provided directly in the match.sni array viz shine.shine.caddy.test.shinenelson.xyz and something.shine.caddy.test.shinenelson.xyz ( Of course, shine.caddy.test.shinenelson.xyz wouldn’t work because it would not match in the host matcher nor is it an SNI on the TLS certificate; that was me just confirming that it wouldn’t work. )
Anything random that is supposed to match the wildcard SNI *.shine.caddy.test.shinenelson.xyz would throw me :
TLS alert, internal error (592):
error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
4. Error messages and/or full log output:
caddy ( server ) :
http: TLS handshake error from 68.183.87.23:60752: no server TLS configuration available for ClientHello: &{CipherSuites:[4866 4867 4865 49196 49200 159 52393 52392 52394 49195 49199 158 49188 49192 107 49187 49191 103 49162 49172 57 49161 49171 51 157 156 61 60 53 47 255] ServerName:anything.shine.caddy.test.shinenelson.xyz SupportedCurves:[29 23 30 25 24] SupportedPoints:[0 1 2] SignatureSchemes:[1027 1283 1539 2055 2056 2057 2058 2059 2052 2053 2054 1025 1281 1537 771 515 769 513 770 514 1026 1282 1538] SupportedProtos:[h2 http/1.1] SupportedVersions:[772 771 770 769] Conn:0xc00022ad38 config:0xc0004bd680}
curl ( client ) :
curl -kv https://anything.shine.caddy.test.shinenelson.xyz
* Trying 68.183.87.23:443...
* Connected to anything.shine.caddy.test.shinenelson.xyz (68.183.87.23) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
5. What I already tried:
Different combinations of match.sni :
- adding more subdomains to the host SNI
- putting the wildcard SNI at the top, then bottom of the array
- exclusive wildcard SNI
*.shine.caddy.test.shinenelson.xyz
the version pasted above is the final version after many iterations of combinations above
I also tried adapting a Caddyfile ( my default fallback whenever my JSON fails )
*.shine.caddy.test.shinenelson.xyz {
tls /etc/letsencrypt/live/caddy.test.shinenelson.xyz/fullchain.pem /etc/letsencrypt/live/caddy.test.shinenelson.xyz/privkey.pem
}
and then compared the results. They were pretty much the same.
I didn’t know how to disable automatic-https via the Caddyfile, so, that much was hand-rolled in. Also, the adapted JSON had a nested handler with a subroute ( I didn’t think that was relevant, but tried anyway, though not extensively ).
6. Links to relevant resources:
I found this old issue ( #3004 ) on github that were already fixed in commit 4a07a5d in PR #3005 which is probably remotely related to the problem. It isn’t relevant here because both issues described in #3004 were fixed.
