Using Previously Generated Certs for internal

[chromag9 (Chromag)]

1. Caddy version: v2.4.6

2. How I run Caddy:

Docker

a. System environment:

Arch Linux

b. Command:

N/A

c. Service/unit/compose file:

version: "3.7"

services:
  caddy:
    container_name: caddy
    hostname: proxy
    image: caddy:latest
    restart: unless-stopped
    volumes:
      - $PWD/Caddyfile:/etc/caddy/Caddyfile
      - $PWD/site:/srv
      - $PWD/data:/data
      - $PWD/config:/config
      - $PWD/cert:/cert
    networks:
      default:
        ipv4_address: 172.30.0.3

networks:
  default:
    external: true
    name: proxy

d. My complete Caddyfile or JSON config:

http://proxy.lan {
  redir https://proxy.lan{uri}
}

https://proxy.lan {
  tls /cert/lancrt.pem /cert/lankey.pem

  respond "This is a test"
}

3. The problem I’m having:

I already have my own self-signed certificates for handling local LAN proxying. My other containers are already using these certs so I don’t want to use the Caddy internal cert generation and I obviously don’t want it reaching out to Let’s Encrypt or ZeroSSL for certs.

When using an internal DNS name like proxy.lan (in this example) Caddy is trying to reach out to Let’s Encrypt or ZeroSSL to get a cert.

If I omit the domain name and just use a port (:443) it starts up fine without trying to get an external cert. I know Caddy has an internal tls option but this will cause it to generate it’s own self-signed certificates and I’d prefer to use the one’s that I have.

Is there a tls option or something I’m missing?

4. Error messages and/or full log output:

N/A

5. What I already tried:

Setting the tls option to internal.

6. Links to relevant resources:

[chromag9 (Chromag)]

I figured it out after digging around through search results, documentation and github issues. So there is this blurb in the documentation that put me on the right track.

There is a small box in the Concepts → Addresses section that says this:

Automatic HTTPS is enabled if your site’s address contains a hostname or IP address. This behavior is purely implicit, however, so it never overrides any explicit configuration. For example, if the site’s address is http://example.com, auto-HTTPS will not activate because the scheme is explicitly http://.

I decided perhaps I should give the Automatic HTTPS page a read, specifically the Activation section.

So the answer in my particular situation is to disable it. In the top global section of the Caddyfile I added:

{
  auto_https off
}

I would have preferred the option to ignore the loaded certificates because I figured if I included them using the tls directive they would be considered “loaded” but apparently not. In this situation ignoring loaded certificates didn’t work so I had to just disable it.

That being said - I understand that in most circumstances this is probably a bad idea!

In my circumstance I’m only working with a proxy in a small local network (specifically a proxy for my different Docker containers). This particular network isn’t even available outside my local machine.

I will probably be rolling Caddy out on my home network this weekend and in that scenario I will definitely not be disabling the automatic HTTPS option.