Temporarily switching back to old certificate

Help
1

1. Caddy version (caddy version):

Caddy v1.0.3 (h1:i9gRhBgvc5ifchwWtSe7pDpsdS9+Q0Rw9oYQmYUTw1w=)

2. How I run Caddy:

docker compose

a. System environment:

Docker

b. Command:

See above

c. Service/unit/compose file:

  caddy:
    container_name: caddy
    environment:
      - ACME_AGREE=true
      - CADDY_TLS
      - DOMAIN_NAME
      - TZ=Europe/London
    image: abiosoft/caddy
    ports:
      - "443:443"
      - "80:80"
    restart: always
    volumes:
      - ./deployment/Caddyfile:/etc/Caddyfile
      - django_static:/app/static
      - django_media:/app/media
      - caddy_certs:/root/.caddy

d. My complete Caddyfile or JSON config:

{$DOMAIN_NAME} {
    tls {$CADDY_TLS}
    errors stderr
    gzip
}

3. The problem I’m having:

We have an iot device that connects to caddy over TLS, which needs to always have a valid root certificate. It has valid certificates for the next 5-10 years (hopefully) but inevitably it will be forgotten about and when caddy automatically gets a new cert with a new root, the devices in the field won’t be able to connect.
In theory we should be using self-signed certs for this use case as we control client and server but it’s more convenient to just use caddy and letsencrypt.

So my question is, if we were to get in a mess where caddy automatically gets a new cert with a new root, could we temporarily use the old certificate to give us time to update the devices in the field?
I have looked around in the caddy container for old certificates and can’t find any, yet people have mentioned cleaning up old certificates. I am mounting the .caddy folder so current certs are retained but perhaps there is another folder for older certificates I’m not mounting?

My understanding is that caddy gets new certs every 60 days but they expire after 90 days so we would have 30 days of a valid cert to fix the problem, is this correct?

2

Caddy v1 is now EOL and no longer supported. Please upgrade to Caddy v2.

The good news is we have an official docker image now: Docker Hub. Please make sure to review to documentation on that page for proper usage.

Updating your config should be simple. I assume the CADDY_TLS env is an email?

{$DOMAIN_NAME} {
	tls {$CADDY_TLS}

	root * /srv
	encode gzip
	file_server
}

And mount your static content to /srv.

3

Thanks, I have upgraded to caddy v2. My caddy config is as you’ve described and docker-compose is now:

  caddy:
    container_name: caddy
    environment:
      - CADDY_TLS
      - DOMAIN_NAME
      - TZ=Europe/London
    image: caddy
    ports:
      - "443:443"
      - "80:80"
    restart: always
    volumes:
      - ./deployment/Caddyfile:/etc/caddy/Caddyfile
      - caddy_config:/config
      - caddy_data:/data

Caddy version is now:
v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

I can see that current certificates are now in /data/caddy/certificates, but where are old certificates? Obviously there won’t be any because it’s a new container with new mount, but where would they be in the future? I don’t know how to force caddy to get a new certificate so I can see what happens to old ones.

4

When you use a named volume, they get stored somewhere in /var/lib/docker. You can use the Docker commands to find their real locations:

5

I don’t mean where are they on the host, I mean where are they in the container itself?

6

They’re in /data, as documented: Docker Hub

7

That only mentions current certificates, are previous certificates also stored there or just deleted?

8

I don’t understand what you mean by “previous certificates”. Caddy v1 and v2 are not compatible, Caddy v2 is a complete rewrite.

9

Sorry, I mean the certificate and key which caddy was using before a new one was re-issued. A new certificate is obtained from LetsEncrypt every 60 days, what happens to the old one which still has 30 days until expiry? Am I completely misunderstanding the process?

10

Caddy renews 90 day certs 30 days out. It reuses the private key for renewals. When a cert is renewed, the new one overwrites the old one because the old one is no longer needed.

11

Thanks, that makes sense. I believe if I did get into a situation where LetsEncrypt root changed and devices in the field weren’t trusting that root, I could probably use --prefered-chain with certbot to use the old root. Maybe.

12

Why? Just configure the preferred chain in Caddy.

13

How? I searched for preferred chain in documentation and didn’t find anything, and I can’t see anything at tls (Caddyfile directive) — Caddy Documentation.

14

Ah, it’s in the latest beta, so there’s no docs yet: caddytls: Support ACME alt cert chain preferences · caddyserver/caddy@95af426 · GitHub

15

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