I keep getting net::ERR_CERT_DATE_INVALID after not running caddy for a few days

1. The problem I’m having:

I run caddy locally for development, but sometimes I work on other projects for some time before returning to the caddy-powered projects. Every time I leave for a few days or weeks and come back, I get net::ERR_CERT_DATE_INVALID in my browser when accessing the caddy server.

2. Error messages and/or full log output:

Your connection is not private
Attackers might be trying to steal your information from local.mydomain.net (for example, passwords, messages, or credit cards). Learn more about this warning
net::ERR_CERT_DATE_INVALID

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

brew install caddy

a. System environment:

MacOS Sonoma 14.6.1 (23G93)
I have Docker installed, but I am not using it to run Caddy.

b. Command:

caddy run --config=path/to/my/config

c. Service/unit/compose file:

Not using Docker, systemd nor Kubernetes.

d. My complete Caddy config:

local.mydomain.net {
	tls internal

	reverse_proxy https://www.qa.mydomain.net {
		header_up Host {upstream_hostport}
	}

	reverse_proxy /dev/hello-world* 127.0.0.1:51501

	handle_errors 502 {
		reverse_proxy https://www.qa.mydomain.net {
			header_up Host {upstream_hostport}
		}
	}
}

5. Links to relevant resources:

I’ve found this other thread that seems related, so I went and did some checks based on the recommendations there.

I have the caddy Local Authority installed in my keychain as you can see:

I’ve also verified that clicking “Manage certificates” in my Chrome’s Privacy and Security settings directly opens my MacOS system keychain:
image

Unfortunately Chrome caches Caddy’s short-lived certificates way too long. It shouldn’t do so, it should read the lifetime of the certificate and never cache it longer than the expiry time. It’s a bug we’re aware of with Chrome but they refused to fix it. You should be able to get around it by hard-refreshing (ctrl+shift+r), or using a different browser (e.g. Firefox) without that bug.

If you’re doing this as an attempt at retries, you should instead use lb_try_duration or lb_retries on your main reverse_proxy. reverse_proxy (Caddyfile directive) — Caddy Documentation

2 Likes

If you’re doing this as an attempt at retries, you should instead use lb_try_duration or lb_retries on your main reverse_proxy . reverse_proxy (Caddyfile directive) — Caddy Documentation

Not attempting retries. I want to reverse proxy to a remote domain if nothing happens to be running locally on port 51501.

But uh:

1 Like

Yes that is intentional as well. I want to proxy ALL traffic to that domain EXCEPT the ones on the /dev/hello-world* path. And if 127.0.0.1:51501 happens to be down, traffic to that route should be sent to https://www.qa.mydomain.net as well.

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