HTTPS no longer works, SEC_E_INVALID_TOKEN

Help
1

1. Caddy version:

v2.6.3 h1:QRVBNIqfpqZ1eJacY44I6eUC1OcxQ8D04EKImzpj7S8=

2. How I installed, and run Caddy:

Downloaded executable, run at command line

a. System environment:

Windows Server 2019

b. Command:

caddy run

c. Service/unit/compose file:

None

d. My complete Caddy config:

:2015 {
	respond "Hello, world!"
}

3. The problem I’m having:

HTTP serves fine, HTTPS fails.

This was working before going down the Docker rabbit hole so I stripped the reverse proxy and static files so it’s the bare minimum. Caddyfile for debugging.

4. Error messages and/or full log output:

caddy run:

2023/02/15 04:20:05.451 e[34mINFOe[0m   using adjacent Caddyfile
2023/02/15 04:20:05.461 e[34mINFOe[0m   admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/02/15 04:20:05.461 e[34mINFOe[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000328690"}
2023/02/15 04:20:05.461 e[34mINFOe[0m   http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/02/15 04:20:05.461 e[34mINFOe[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Administrator\\AppData\\Roaming\\Caddy"}
2023/02/15 04:20:05.461 e[34mINFOe[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\Administrator\\AppData\\Roaming\\Caddy\\autosave.json"}
2023/02/15 04:20:05.461 e[34mINFOe[0m   serving initial configuration
2023/02/15 04:20:05.461 e[34mINFOe[0m   tls     finished cleaning storage units

curl -v http://localhost:2015

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
> GET / HTTP/1.1
> Host: localhost:2015
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Server: Caddy
< Date: Wed, 15 Feb 2023 04:26:40 GMT
< Content-Length: 13
<
Hello, world!* Connection #0 to host localhost left intact

curl -v https://localhost:2015

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: SEC_E_INVALID_TOKEN (0x80090308) - The token supplied to the function is invalid
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_INVALID_TOKEN (0x80090308) - The token supplied to the function is invalid

caddy trust

2023/02/15 04:28:10.294 e[34mINFOe[0m   root certificate is already trusted by system   {"path": "localhost:2019/pki/ca/local"}

5. What I already tried:

Stripped Caddyfile to bare minimum, tried caddy trust again. The solution I worked out here in my first thread with Docker is still working. I did a clean boot and tested Caddy standalone, those responses are included above. After that failure I closed the Caddy started at command line and ran my Docker version and HTTPS came right up.

6. Links to relevant resources:

2

A single instance of standard Caddy can’t multiplex HTTP and HTTPS on the same port. Trying to access http://localhost:2015 and https://localhost:2015, barring extraneous circumstances, should never work at the same time. It will require separate ports, one for each scheme.

In your case, Caddy is serving HTTP only with the Caddyfile you’ve specified. This is because you have not specified a hostname in the Caddyfile, so Caddy cannot manage a certificate (not even a self-signed one) without also enabling On-Demand TLS.

2 Likes
3

Technically it can, but it’s opt-in via some funky config. You can add this to your global options:

{
	servers :2015 {
		listener_wrappers {
			http_redirect
			tls
		}
	}
}

The http_redirect listener wrapper will detect HTTP connections and serve a redirect to the same port but with https:// instead.

1 Like
4

As I mentioned it was working with a more complex Caddyfile before I tried using Docker. I had no problem hitting https://localhost:2015 with this config earlier:

:2015 {
	encode zstd gzip
	log

	handle /api/* {
		reverse_proxy localhost:3000
	}

	handle {
		root * public
		try_files {path} index.html
		file_server
	}
}

I don’t know if I have to make other changes but including your suggestion my Caddyfile looks like this:

{
	servers :2015 {
		listener_wrappers {
			http_redirect
			tls
		}
	}
}
:2015 {
	respond "Hello, world!"
}

And it produces the same error. Here’s Caddy’s startup log:

2023/02/15 05:45:48.472 e[34mINFOe[0m   using adjacent Caddyfile
2023/02/15 05:45:48.488 e[34mINFOe[0m   admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/02/15 05:45:48.488 e[34mINFOe[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0001b2000"}
2023/02/15 05:45:48.488 e[34mINFOe[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Administrator\\AppData\\Roaming\\Caddy"}
2023/02/15 05:45:48.488 e[34mINFOe[0m   http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/02/15 05:45:48.491 e[34mINFOe[0m   tls     finished cleaning storage units
2023/02/15 05:45:48.491 e[34mINFOe[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\Administrator\\AppData\\Roaming\\Caddy\\autosave.json"}
2023/02/15 05:45:48.491 e[34mINFOe[0m   serving initial configuration

Here’s curl -v http://localhost:2015

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
> GET / HTTP/1.1
> Host: localhost:2015
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 308 Permanent Redirect
< Location: https://localhost:2015/
< Content-Length: 0
<
* Closing connection 0

Here’s curl -v https://localhost:2015:

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: SEC_E_INVALID_TOKEN (0x80090308) - The token supplied to the function is invalid
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_INVALID_TOKEN (0x80090308) - The token supplied to the function is invalid
5

I’m sure that’s not true. There’s no way for a config with a site block of :2015 to serve HTTPS. You’re probably misremembering things.

Like I said in the other thread, you should use https://localhost:2015 as your site address to serve HTTPS on that port, and manage a certificate for localhost.

Yeah, that alone will not enable HTTPS. That’s only to enable redirects from HTTP to HTTPS on that port.

1 Like
6

Ok, I guess I’m just lost. Following that tip my Caddyfile looks like this:

{
	servers :2015 {
		listener_wrappers {
			http_redirect
			tls
		}
	}
}
https://localhost:2015 {
	respond "Hello, world!"
}

And now Caddy won’t start up:

2023/02/15 06:06:28.213 e[34mINFOe[0m   using adjacent Caddyfile
2023/02/15 06:06:28.213 e[34mINFOe[0m   admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/02/15 06:06:28.213 e[34mINFOe[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0001d07e0"}
2023/02/15 06:06:28.213 e[34mINFOe[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/02/15 06:06:28.213 e[34mINFOe[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Administrator\\AppData\\Roaming\\Caddy"}
2023/02/15 06:06:28.213 e[34mINFOe[0m   tls     finished cleaning storage units
2023/02/15 06:06:28.234 e[34mINFOe[0m   pki.ca.local    root certificate is already trusted by system   {"path": "storage:pki/authorities/local/root.crt"}
2023/02/15 06:06:28.234 e[34mINFOe[0m   http    enabling HTTP/3 listener        {"addr": ":2015"}
2023/02/15 06:06:28.235 e[34mINFOe[0m   http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/02/15 06:06:28.236 e[34mINFOe[0m   tls.cache.maintenance   stopped background certificate maintenance      {"cache": "0xc0001d07e0"}
Error: loading initial config: loading new config: http app module: start: listening on :80: listen tcp :80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.cp :80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

I guess I need a way to tell it not to use port 80 even though it’s nowhere to be found in the config?

7

Yeah, a couple ways. Either set the http_port global option to something else, or set the auto_https disable_redirects global option.

Caddy is designed to play best when it’s using the default ports (80 and 443). When you try to use other ports, it gets complicated.

I know you said you’re using IIS on that server on ports 80/443, but you could reconfigure IIS to use different ports, then have Caddy use 80/443 and have it proxy any traffic for the hostnames you want IIS to serve to IIS’s ports. It would make this a lot simpler.

1 Like
8

That did it…kinda. Here’s the Caddyfile:

{
	http_port 2010
	servers :2015 {
		listener_wrappers {
			http_redirect
			tls
		}
	}
}
https://localhost:2015 {
	respond "Hello, world!"
}

Now when I go to https://localhost:2015/ I get “Hello World!” in the browser but curl doesn’t get that. Here’s the startup from Caddy:

2023/02/15 06:18:46.375 e[34mINFOe[0m   using adjacent Caddyfile
2023/02/15 06:18:46.380 e[34mINFOe[0m   admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/02/15 06:18:46.381 e[34mINFOe[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0001da7e0"}
2023/02/15 06:18:46.381 e[34mINFOe[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/02/15 06:18:46.382 e[34mINFOe[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Administrator\\AppData\\Roaming\\Caddy"}
2023/02/15 06:18:46.383 e[34mINFOe[0m   tls     finished cleaning storage units
2023/02/15 06:18:46.395 e[34mINFOe[0m   pki.ca.local    root certificate is already trusted by system   {"path": "storage:pki/authorities/local/root.crt"}
2023/02/15 06:18:46.395 e[34mINFOe[0m   http    enabling HTTP/3 listener        {"addr": ":2015"}
2023/02/15 06:18:46.395 e[34mINFOe[0m   http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/02/15 06:18:46.395 e[34mINFOe[0m   http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/02/15 06:18:46.395 e[34mINFOe[0m   http    enabling automatic TLS certificate management   {"domains": ["localhost"]}
2023/02/15 06:18:46.395 e[34mINFOe[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\Administrator\\AppData\\Roaming\\Caddy\\autosave.json"}
2023/02/15 06:18:46.395 e[34mINFOe[0m   serving initial configuration
2023/02/15 06:18:46.400 e[34mINFOe[0m   tls.obtain      acquiring lock  {"identifier": "localhost"}
2023/02/15 06:18:46.403 e[34mINFOe[0m   tls.obtain      lock acquired   {"identifier": "localhost"}
2023/02/15 06:18:46.404 e[34mINFOe[0m   tls.obtain      obtaining certificate   {"identifier": "localhost"}
2023/02/15 06:18:46.467 e[34mINFOe[0m   tls.obtain      certificate obtained successfully       {"identifier": "localhost"}
2023/02/15 06:18:46.467 e[34mINFOe[0m   tls.obtain      releasing lock  {"identifier": "localhost"}
2023/02/15 06:18:46.467 e[33mWARNe[0m   tls     stapling OCSP   {"error": "no OCSP stapling for [localhost]: no OCSP server specified in certificate", "identifiers": ["localhost"]}

curl -v http://localhost:2015:

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
> GET / HTTP/1.1
> Host: localhost:2015
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 308 Permanent Redirect
< Location: https://localhost:2015/
< Content-Length: 0
<
* Closing connection 0

curl -v https://localhost:2015:

*   Trying 127.0.0.1:2015...
* Connected to localhost (127.0.0.1) port 2015 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

It’s working here and with my larger project so thanks for all the help again, just worried about that last curl result. I’m going to try my real Caddy test and see if that works.

9

That’s a problem with curl itself I think, not Caddy. Make sure you have the latest version of curl etc.

3 Likes
10

try with -k to ignore curl issues with the certificate verification:

curl -kv https://localhost:2015
11

That kinda defeats the purpose @timelordx, they want trusted TLS.

12

My apologies. I made my suggestion only based on the localhost URL and the revocation error message. I assumed there was no revocation service involved for localhost, so to get rid of that I suggested -k. Another assumption I made was that Caddy server and curl client were not sharing the same CA. To be honest, I made a lot of assumptions here.

1 Like
13

Normally true, we try to avoid -k, but I think the suggestion to use -k is fine since curl is the one with the issue in this case, and we’re troubleshooting.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.