Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wildcard SNIs not being matched #3163

Closed
shinenelson opened this issue Mar 20, 2020 · 1 comment
Closed

wildcard SNIs not being matched #3163

shinenelson opened this issue Mar 20, 2020 · 1 comment
Labels
bug

Comments

@shinenelson
Copy link

@shinenelson shinenelson commented Mar 20, 2020

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:

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 :

  1. adding more subdomains to the host SNI
  2. putting the wildcard SNI at the top, then bottom of the array
  3. 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 ).

mholt referenced this issue Mar 20, 2020
@mholt mholt added bug v2 labels Mar 20, 2020
@mholt mholt added this to the v2.0.0-beta.19 milestone Mar 20, 2020
@shinenelson

This comment has been minimized.

Copy link
Author

@shinenelson shinenelson commented Mar 20, 2020

I've tested and confirmed that commit 3c1def2 fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.