Fallback page if cert cannot be issued

Help
1

1. Output of caddy version:

v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=

2. How I run Caddy:

I start Caddy in docker

a. System environment:

Docker caddy:2.5.1-alpine image

b. Command:

caddy run --config /etc/caddy/caddy.yaml --adapter yaml

c. Service/unit/compose file:

version: '3.5'

services:
  proxy:
    build:
      context: .
    restart: always
    environment:
      UPSTREAM: "my_upstream:8080"
      ZEROSSL_API_KEY: ""
      LETSENCRYPT_EMAIL: ""
      REDIS_STORAGE_ADDRESS: ""
    volumes:
      - ./caddy.yaml:/etc/caddy/caddy.yaml
    ports:
      - 80:80
      - 443:443
      - 2019:2019 # Admin

d. My complete Caddy config:

apps:
  http:
    servers:
      srv_main:
        listen:
          - :443

        automatic_https:
          disable_redirects: true

        read_timeout: 15s
        write_timeout: 15s
        idle_timeout: 10s

        max_header_bytes: 16384 # 16kb

        routes:
          - match: # matches anything
            handle:
              - handler: encode
                encodings:
                  gzip: {}
                  zstd: {}
                prefer:
                  - zstd
                  - gzip
              - handler: reverse_proxy
                upstreams:
                  - dial: "#{$UPSTREAM}"
                headers:
                  request:
                    set:
                      X-Forwarded-Host:
                        - "{http.request.host}"
                      X-Real-IP:
                        - "{http.request.remote.host}"
                      Connection:
                        - ""
                transport:
                  protocol: http
                  response_header_timeout: 30s

        logs:
          default_logger_name: log0

  tls:
    automation:
      policies:
        - on_demand: true
          issuers:
            - module: zerossl
              api_key: "#{$ZEROSSL_API_KEY}"
            - module: acme
              email: "#{$LETSENCRYPT_EMAIL}"
      on_demand:
        rate_limit:
          interval: 1m
          burst: 600
        ask: "#{$DOMAIN_VALIDATION_ENDPOINT}"
      storage_clean_interval: 24h
    cache:
      capacity: 40000
    session_tickets:
      disabled: true

storage:
  module: redis
  address: "#{$REDIS_STORAGE_ADDRESS}"
  key_prefix: caddytls
  password: ""
  timeout: 5
  tls_enabled: false
  tls_insecure: true
  value_prefix: caddy-storage-redis

admin:
  listen: 0.0.0.0:2019

3. The problem I’m having:

I have an ask endpoint in TLS on_demand configuration to check if domain is valid before issuing the certificate. If domain is not valid or any other cert issunig error there, user just sees the ugly “This site can’t provide a secure connection ERR_SSL_PROTOCOL_ERROR” in his browser. Is ti possible to respond with redirect to some fallback page? To the port 80 maybe.
Thanks.

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

2

Please upgrade to v2.6.2. You’re using an old version and you’re probably missing some important fixes.

You’re missing a volume for /data and /config, which are important to avoid data loss. If you recreate the container for any reason (upgrade Caddy for example), then all your certs and keys will be wiped out. That’s bad. Especially when using On-Demand TLS, because it would force needing to reissue all the certificates for the domains you’re managing.

I recommend using unless_stopped instead of always. Just gives you a bit more flexibility with shutting down Caddy temporarily if you need to.

FYI you can just omit match: if you feel like it, which is the same thing.

You don’t need this, Caddy already sets this header automatically.

Are you sure you want to do this? I think it would break websocket connections, for example.

Unfortunately, no that’s not possible. If a client is trying to connect over HTTPS, then the server can only send content to them if the TLS handshake succeeds. Browsers (and other clients) won’t trust any content the server sends unless a valid certificate is used.

3

Thank you for your answers and clues!

You’re missing a volume for /data and /config, which are important to avoid data loss. If you recreate the container for any reason (upgrade Caddy for example), then all your certs and keys will be wiped out. That’s bad. Especially when using On-Demand TLS, because it would force needing to reissue all the certificates for the domains you’re managing.

We use Redis for storing all cert data. So it will not be lost when container is re-created.
Thanks.

1 Like
4

Ah right, I missed that, at the bottom of the config.

Still though, /data may be used for other things like remote admin config, if you eventually use that, to store an instance ID. Not something you need now, but something to keep in mind, that Caddy may still write there in certain edgecase situations.

1 Like
5

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