Yes - you’re running Caddy in Docker. When it installs its local-only certificate authority, it does so… inside the Docker container. The actual Docker host (presumably where you’re running your browser) still won’t trust Caddy.
Quirk of interaction between Docker NAT, and SNI (or specifically the lack thereof).
Browsers don’t send SNI for IP addresses, so Caddy infers the server name from the IP address the client is connecting to (i.e. its own IP address). You might be connecting to a 192.168 address but the packets are being redirected to the 172.17 address, which explains why you’re seeing no certificate available for '172.17.0.2'.
Caddy doesn’t appear to issue internal certificates for wildcarded IP addresses, not even with TLS on demand, which is why 172.17.0.* doesn’t work as a site label for this purpose.
The best way to fix this is to point an actual domain name at your Caddy server and add that domain name as a site address in your Caddyfile. That will ensure that Caddy knows exactly which certificate it needs, and browsers will send SNI to indicate this to Caddy so that it can select the appropriate HTTPS certificate.