Accessing HTTPS application behind HAProxy: no matching certificates / wrong identifier used

[tcoch]

Hello there,

I'm trying since yesterday, to create a new symfony project.
I pulled this repo, and then:

• If I "do nothing", the base Symfony page is accessible at https://localhost/
• If I try to change the exposed port on the compose file, I can access https://localhost:<PORT>/
  Good.

Usually, what I do is actually : set up a new DNS alias project.tcoch.local, declare this in a DNS server, and in my HAProxy configuration. This means that I can work on multiple projects not by adressing https://localhost:<PORT_FOR_PROJECT>/, but rather https://project.tcoch.local/.

Up until a few days (weeks ?) ago, this worked fine for me, by providing the certificate via a volume mount in compose.yaml and adding CADDY_SERVER_EXTRA_DIRECTIVES: "tls /etc/caddy/certs/tls.pem /etc/caddy/certs/tls.key" (as per tls.md).

But since yesterday, no luck. I got this error:

no matching certificates and no custom selection logic {"identifier": "172.21.0.2"}

Since I get logs when trying to access https://project.tcoch.local, I believe that DNS and HAPorxy (which I liek tripled-checked) is fine.
Somehow, Caddy server sees this SNI in the logs, but for some reason, actually looks for an auto-generated certificate, based on the container IP ?

I do not see anything in this repo and its recent PR that could cause this. However, there has been some new version v1.5 released recently. Could it be the source?

I'm not sure where to look. If you guys need more info / logs, please feel free to ask, I'll provide as soon as I can.

[maxhelias]

Hi!
I'm not sure this is directly related to the new FrankenPHP version, unless it also bumped the embedded Caddy version, since SNI handling and certificate matching are mostly managed by Caddy itself.

Could you try using a previous version of the image to see if the issue disappears?

Might also be worth checking the recent changes in the FrankenPHP or Caddy repositories — perhaps something changed in how certificates are selected for custom domains.

[tcoch]

Hi @maxhelias,
I agree with you, the issue seems to be on the caddy server side.

I indeed tried different versions:

• Brand new project, latest version of this repo: custom certificate not working
• Brand new project, but using base image dunglas/frankenphp:1.5-php8.3: custom certificate not working
• Brand new project, but using base image dunglas/frankenphp:1.3-php8.3 (which I use in a project, currently in production): custom certificate not working
• Using an older frankenphp (from an older, currently working project), with base image dunglas/frankenphp:1.3-php8.3: symfony project created from this config, custom certificate is working this time.

From this, I would say that the problem is not with the frankenphp docker image, but with the Caddy server configuration.

I got those logs too.

PHP app ready!
2025/04/10 09:41:39.830 INFO    using config from file  {"file": "/etc/caddy/Caddyfile"}
2025/04/10 09:41:39.831 INFO    adapted config to JSON  {"adapter": "caddyfile"}
2025/04/10 09:41:39.831 WARN    Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies    {"adapter": "caddyfile", "file": "/etc/caddy/Caddyfile", "line": 9}
2025/04/10 09:41:39.832 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//[::1]:2019", "//127.0.0.1:2019", "//localhost:2019"]}
2025/04/10 09:41:39.832 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0004bd500"}
2025/04/10 09:41:39.834 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [*.tcoch.local]: no OCSP server specified in certificate"}
2025/04/10 09:41:39.834 INFO    http.auto_https skipping automatic certificate management because one or more matching certificates are already loaded  {"domain": "project.tcoch.local", "server_name": "srv0"}
2025/04/10 09:41:39.834 INFO    http.auto_https enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2025/04/10 09:41:39.834 WARN    http.handlers.mercure   Setting the transport_url or the MERCURE_TRANSPORT_URL environment variable is deprecated, use the "transport" directive instead
2025/04/10 09:41:39.835 WARN    http    HTTP/2 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}
2025/04/10 09:41:39.835 WARN    http    HTTP/3 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}
2025/04/10 09:41:39.835 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2025/04/10 09:41:39.835 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2025/04/10 09:41:39.835 INFO    failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
2025/04/10 09:41:39.835 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2025/04/10 09:41:39.837 INFO    tls     storage cleaning happened too recently; skipping for now        {"storage": "FileStorage:/data/caddy", "instance": "c880c0c5-3db8-46f2-9724-e54485775ba4", "try_again": "2025/04/11 09:41:39.837", "try_again_in": 86399.999999323}
2025/04/10 09:41:39.837 INFO    tls     finished cleaning storage units
2025/04/10 09:41:39.964 INFO    frankenphp      FrankenPHP started 🐘   {"php_version": "8.3.19", "num_threads": 5, "max_threads": 5}
2025/04/10 09:41:39.964 INFO    autosaved config (load with --resume flag)      {"file": "/config/caddy/autosave.json"}
2025/04/10 09:41:39.964 INFO    serving initial configuration
2025/04/10 09:41:39.966 INFO    watcher watching config file for changes        {"config_file": "/etc/caddy/Caddyfile"}

Could you help me understand why I got those two lines in particular:

2025/04/10 09:41:39.835 WARN    http    HTTP/2 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}
2025/04/10 09:41:39.835 WARN    http    HTTP/3 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}

I'll try on Tuesday (can't do it before) to start from the old project and update the caddy files, little by little, see if I can isolate the problem.

And my `compose.yaml`:

services:
  php:
    image: ${IMAGES_PREFIX:-}app-php
    restart: unless-stopped
    environment:
      SERVER_NAME: ${SERVER_NAME}:443
      MERCURE_PUBLISHER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeThisMercureHubJWTSecretKey!}
      MERCURE_SUBSCRIBER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeThisMercureHubJWTSecretKey!}
      # Run "composer require symfony/orm-pack" to install and configure Doctrine ORM
      DATABASE_URL: postgresql://${POSTGRES_USER:-app}:${POSTGRES_PASSWORD:-!ChangeMe!}@database:5432/${POSTGRES_DB:-app}?serverVersion=${POSTGRES_VERSION:-15}&charset=${POSTGRES_CHARSET:-utf8}
      # Run "composer require symfony/mercure-bundle" to install and configure the Mercure integration
      MERCURE_URL: ${CADDY_MERCURE_URL:-http://php/.well-known/mercure}
      MERCURE_PUBLIC_URL: ${CADDY_MERCURE_PUBLIC_URL:-https://${SERVER_NAME:-localhost}:${HTTPS_PORT:-443}/.well-known/mercure}
      MERCURE_JWT_SECRET: ${CADDY_MERCURE_JWT_SECRET:-!ChangeThisMercureHubJWTSecretKey!}
      # The two next lines can be removed after initial installation
      SYMFONY_VERSION: ${SYMFONY_VERSION:-}
      STABILITY: ${STABILITY:-stable}
      CADDY_SERVER_EXTRA_DIRECTIVES: "tls /etc/caddy/certs/tls.pem /etc/caddy/certs/tls.key"
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      - ${CERT_PEM}:/etc/caddy/certs/tls.pem
      - ${CERT_KEY}:/etc/caddy/certs/tls.key

I have SERVER_NAME, CERT_PEM and CERT_KEY defined in .env file.

One more thing:

• https://localhost:<PORT>/ does not work: that's expected (wrong SNI)
• https://project.tcoch.local/ does not work: that's the problem. This goes through my haproxy before pointing to <COMPUTER_IP>/.
• Now, if I set project.tcoch.local to resolve to COMPUTER_IP, accessing https://project.tcoch.local:<PORT>/ works fine ...
  So from that, I'd say it's my HAProxy that does something wrong?

[tcoch]

I figured it out

When it works, Caddy server configuration is this:

root@f4e302f5dd89:/app# curl localhost:2019/config/apps/http/servers/srv0/tls_connection_policies
[{"certificate_selection":{"any_tag":["cert0"]}}]

Where it doesn't work, I got this:

root@273d373e6d47:/app# curl localhost:2019/config/apps/http/servers/srv0/tls_connection_policies
[{"certificate_selection":{"any_tag":["cert0"]},"match":{"sni":["project.tcoch.local"]}},{}]

So there is a new default configuration on Caddy server side, that bugs me.

I've opened an issue over there: caddyserver/caddy#6946.