You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
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 ).
The text was updated successfully, but these errors were encountered:
converting a community post into an issue since this was confirmed as a TODO in
modules/caddytls/matchers.go#L41
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:
b. Command:
sudo caddy run --config config.caddy.json
( I run withsudo
so that caddy can access/etc/letsencrypt/live
)d. My complete Caddyfile or JSON config:
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 thetest
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 vizshine.shine.caddy.test.shinenelson.xyz
andsomething.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 :4. Error messages and/or full log output:
caddy
( server ) :curl
( client ) :5. What I already tried:
Different combinations of
match.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 )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 asubroute
( I didn't think that was relevant, but tried anyway, though not extensively ).The text was updated successfully, but these errors were encountered: