Trouble running a Flask app over https, using Waitress and Caddy

1. The problem I’m having:

Hello! This may be a very niche problem but I am running a Flask application and serving it through Waitress. Caddy is acting as a reverse proxy. This is all within a Docker Container as well that runs Debian 11 and Python 3.6. I hope to run this over https.

There are two problems I am experiencing.

The first is when I try to connect to my server through a web browser using an HTTP connection. After typing the IP address, the page will say “Client sent an HTTP request to an HTTPS server.”

The second is when I try to connect to my server through a web browser using an HTTPS connection.

The page will display this:
image

I serve the Flask application through Waitress with this code.

from manage import app
from waitress import serve


serve(app, listen='0.0.0.0:5000', threads=4)

2. Error messages and/or full log output:

2024-08-20 13:30:05 Caddy started
2024-08-20 13:30:05 {"level":"info","ts":1724182205.7101378,"msg":"using config from file","file":"/etc/caddy/PW_Caddyfile"}
2024-08-20 13:30:05 {"level":"warn","ts":1724182205.7103899,"logger":"caddyfile","msg":"Unnecessary header_up X-Forwarded-For: the reverse proxy's default behavior is to pass headers to the upstream"}
2024-08-20 13:30:05 {"level":"warn","ts":1724182205.710425,"logger":"caddyfile","msg":"Unnecessary header_up X-Forwarded-Proto: the reverse proxy's default behavior is to pass headers to the upstream"}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.7112877,"msg":"adapted config to JSON","adapter":"caddyfile"}
2024-08-20 13:30:05 {"level":"warn","ts":1724182205.7113397,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/PW_Caddyfile","line":2}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.7123103,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.7125983,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000313400"}
2024-08-20 13:30:05 {"level":"debug","ts":1724182205.8491518,"logger":"events","msg":"event","name":"cached_unmanaged_cert","id":"de3e1c94-89eb-4c23-b0cf-7bb767e7bb6c","origin":"tls","data":{"sans":["nanomicro.byu.edu"]}}
2024-08-20 13:30:05 {"level":"debug","ts":1724182205.8491938,"logger":"tls.cache","msg":"added certificate to cache","subjects":["nanomicro.byu.edu"],"expiration":1736726400,"managed":false,"issuer_key":"","hash":"c956d63645de91c267e9754f8bcefa59fb1aba1b033e856295244aeae41efc20","cache_size":1,"cache_capacity":10000}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.849241,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
2024-08-20 13:30:05 {"level":"debug","ts":1724182205.8528328,"logger":"http.auto_https","msg":"adjusted config","tls":{"automation":{"policies":[{"subjects":["10.37.145.182"]},{}]}},"http":{"servers":{"remaining_auto_https_redirects":{"listen":[":80"],"routes":[{},{}],"logs":{"logger_names":{"10.37.145.182":["log0"]}}},"srv0":{"listen":[":31415"],"routes":[{"handle":[{"handler":"subroute","routes":[{"handle":[{"handler":"vars","root":"./"},{"handler":"reverse_proxy","headers":{"request":{"set":{"Host":["{http.request.host}"],"X-Forwarded-For":["{http.request.remote.host}"],"X-Forwarded-Proto":["{http.request.scheme}"],"X-Real-Ip":["{http.request.remote.host}"]}}},"upstreams":[{"dial":"127.0.0.1:5000"}]}]}]}],"terminal":true}],"tls_connection_policies":[{"match":{"sni":["10.37.145.182"]},"certificate_selection":{"any_tag":["cert0"]}},{}],"automatic_https":{},"logs":{"logger_names":{"10.37.145.182":["log0"]}}}}}}
2024-08-20 13:30:05 {"level":"warn","ts":1724182205.8531919,"logger":"pki.ca.local","msg":"installing root certificate (you might be prompted for password)","path":"storage:pki/authorities/local/root.crt"}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.8534386,"msg":"warning: \"certutil\" is not available, install \"certutil\" with \"apt install libnss3-tools\" or \"yum install nss-tools\" and try again"}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.8534763,"msg":"define JAVA_HOME environment variable to use the Java trust"}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.8553903,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/root/.local/share/caddy"}
2024-08-20 13:30:05 {"level":"info","ts":1724182205.8558648,"logger":"tls","msg":"finished cleaning storage units"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.810972,"msg":"certificate installed properly in linux trusts"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.81116,"logger":"http","msg":"enabling HTTP/3 listener","addr":":31415"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8112955,"msg":"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."}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8114414,"logger":"http","msg":"starting server loop","address":"[::]:31415","tls":true,"http3":true}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8114772,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8115187,"logger":"http","msg":"starting server loop","address":"[::]:80","tls":false,"http3":false}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8115263,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8115313,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["10.37.145.182"]}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8117585,"msg":"autosaved config (load with --resume flag)","file":"/root/.config/caddy/autosave.json"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.811792,"msg":"serving initial configuration"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.812062,"logger":"tls.obtain","msg":"acquiring lock","identifier":"10.37.145.182"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8140306,"logger":"tls.obtain","msg":"lock acquired","identifier":"10.37.145.182"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8142135,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"10.37.145.182"}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8143103,"logger":"events","msg":"event","name":"cert_obtaining","id":"91083013-99c3-4d86-9d75-325e9a98d25e","origin":"tls","data":{"identifier":"10.37.145.182"}}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8144894,"logger":"tls.obtain","msg":"trying issuer 1/1","issuer":"local"}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8149123,"logger":"pki.ca.local","msg":"using intermediate signer","serial":"335355397680664560297744683734270447478","not_before":"2024-08-20 19:30:05 +0000 UTC","not_after":"2024-08-27 19:30:05 +0000 UTC"}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8158832,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"10.37.145.182","issuer":"local"}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8159795,"logger":"events","msg":"event","name":"cert_obtained","id":"4990088b-e325-4ae4-9623-f219f3498780","origin":"tls","data":{"certificate_path":"certificates/local/10.37.145.182/10.37.145.182.crt","csr_pem":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlIZE1JR0VBZ0VBTUFBd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFRSjBmNTVlbmR3REd6ZwpFamVORzgrTGt3MjVzVkZPVWd2L1YwdDh5V2pxWmF2dGF3WEt4dEIxTnJabTNONFpTR1ZhYXNDRStkaVZVOW12CktkdGJ4UGE3b0NJd0lBWUpLb1pJaHZjTkFRa09NUk13RVRBUEJnTlZIUkVFQ0RBR2h3UUtKWkcyTUFvR0NDcUcKU000OUJBTUNBMGdBTUVVQ0lDM0dIQ0l3bU9DMmJRUkp5dXRJb3U0bEZQSHNrbW1BODhCajV0SHFDNkNzQWlFQQp0eGN5Z1RpazN3WER5U1dCUk91cUU4bitFS0E2YWpJZ3N5Wm1yQ3RHSktjPQotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K","identifier":"10.37.145.182","issuer":"local","metadata_path":"certificates/local/10.37.145.182/10.37.145.182.json","private_key_path":"certificates/local/10.37.145.182/10.37.145.182.key","renewal":false,"storage_path":"certificates/local/10.37.145.182"}}
2024-08-20 13:30:06 {"level":"info","ts":1724182206.8159845,"logger":"tls.obtain","msg":"releasing lock","identifier":"10.37.145.182"}
2024-08-20 13:30:06 {"level":"warn","ts":1724182206.8163075,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [10.37.145.182]: no OCSP server specified in certificate","identifiers":["10.37.145.182"]}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8163524,"logger":"tls.cache","msg":"added certificate to cache","subjects":["10.37.145.182"],"expiration":1724225407,"managed":true,"issuer_key":"local","hash":"fb81ec8e09c3dd439c29f7e2617a535b40d2d9f95d262763e4cd5339b148367b","cache_size":2,"cache_capacity":10000}
2024-08-20 13:30:06 {"level":"debug","ts":1724182206.8163702,"logger":"events","msg":"event","name":"cached_managed_cert","id":"9c69ae62-3865-41e1-9257-a121d7c6dc46","origin":"tls","data":{"sans":["10.37.145.182"]}}
2024-08-20 13:33:04 {"level":"debug","ts":1724182384.1544716,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.65.1:20294: EOF"}

3. Caddy version: 2.8.4

4. How I installed and ran Caddy:

a. System environment:

Debian 11
Docker Container FROM python:3.6

b. Command:

Installation: app.dockerfile
RUN apt update && apt-get install -y debian-keyring debian-archive-keyring apt-transport-https
RUN curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
RUN curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
RUN apt update && apt install -y caddy

Run Command: start-app.sh
nohup caddy run --config /etc/caddy/PW_Caddyfile --adapter caddyfile &

c. Service/unit/compose file:

docker-compose.yml

services:
  mongo:
    build:
      context: .
      dockerfile: mongo.dockerfile
    ports:
      - "27017:27017"
    volumes:
      - /Users/nmserver/DockerProjectWiki/backup/2024.07.01.193119:/data/db/backup
    networks:
      - pw-network
    environment:
      MONGO_DATA_DIR: /data/db/backup

  project-wiki:
    build:
      context: .
      dockerfile: app.dockerfile
    networks:
      - pw-network
    ports:
      - "31415:31415"
      - "5000:5000"
    depends_on:
      - mongo
    volumes:
      - /Users/nmserver/DockerProjectWiki/uploads:/app/uploads
      - /Users/nmserver/Desktop/certificates:/etc/ssl/certs
      - /Users/nmserver/DockerProjectWiki/PW_Caddyfile:/etc/caddy/PW_Caddyfile
      
    environment:
      MONGO_DATA_DIR: /data/db/backup
      DB_SERVICE: mongo

networks:
  pw-network:
    driver: bridge


d. My complete Caddy config:

10.37.145.182:31415 {
    root * ./
    reverse_proxy * 127.0.0.1:5000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
    log {
        output file /Project_Wiki_Data/log/caddy.log
    }
    tls /etc/ssl/certs/nanomicro_byu_edu.pem /etc/ssl/certs/nanomicro_byu_edu_key.pem
}

Howdy @w2boy, welcome to the Caddy community.

Could you please run curl -kvL 10.37.145.182 and post the results?

Also, I can see you’ve specified a certificate:

But your logs show Caddy automatically managing this domain with a local issuer:

Caddy shouldn’t have to do this if you’ve supplied a proper cert and key, so I suspect that the configuration you’ve posted isn’t the one that generated those logs.

Also:

I don’t think you need any of these. X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host and Host headers are all set automatically: reverse_proxy (Caddyfile directive) — Caddy Documentation

If you ACTUALLY need X-Real-IP you could set that, but I tend to doubt it as modern upstreams tend to favour or at least support the highly conventional X-Forwarded-For.

You could almost certainly get away with just reverse_proxy 127.0.0.1:5000.

1 Like

Thank you for your reply @Whitestrake
Here are the results for curl -kvL 10.37.145.182

# curl -kvl 10.37.145.182
*   Trying 10.37.145.182:80...
* connect to 10.37.145.182 port 80 failed: Connection refused
* Failed to connect to 10.37.145.182 port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 10.37.145.182 port 80: Connection refused

I have two questions about the certifications and configuration file.

  1. I received my certificates from Digicert but I ran the request commands on my MacBook. Would that cause problems once I tried to use these certifications within a docker container?

  2. I have changed the caddyfile (see below). I have confirmed that it sees this file when I run caddy as I edited it one time to have an invalid directive and it error printed an unrecognized directive as expected. What I don’t understand is why it won’t use my certificate like you mentioned.

That is great to know, I just picked these up from looking at other posts for help but it does seem they aren’t helping.

Updated Caddyfile:

{
debug
}

10.37.145.182:31415 {
    root ./
    reverse_proxy 127.0.0.1:5000

    log /Project_Wiki_Data/log/caddy.log

    tls /etc/ssl/certificates/nanomicro_byu_edu.pem /etc/ssl/certificates/nanomicro_byu_edu_key.pem
}

I also just saw this. An error message was printed when I sent an HTTPS connection to the server. It says:

project-wiki-1  | {"level":"debug","ts":1724261857.9506328,"logger":"events","msg":"event","name":"tls_get_certificate","id":"dbd65baf-edfa-4b10-8203-70d04fd8b12a","origin":"tls","data":{"client_hello":{"CipherSuites":[64250,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"ServerName":"","SupportedCurves":[43690,25497,29,23,24],"SupportedPoints":"AA==","SignatureSchemes":[1027,2052,1025,1283,2053,1281,2054,1537],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[60138,772,771],"RemoteAddr":{"IP":"192.168.65.1","Port":42902,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":31415,"Zone":""}}}}
project-wiki-1  | {"level":"debug","ts":1724261857.950689,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"}
project-wiki-1  | {"level":"debug","ts":1724261857.9506981,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.65.1","remote_port":"42902","server_name":"","remote":"192.168.65.1:42902","identifier":"172.18.0.3","cipher_suites":[64250,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"cert_cache_fill":0.0002,"load_or_obtain_if_necessary":true,"on_demand":false}
project-wiki-1  | {"level":"debug","ts":1724261857.9507785,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.65.1:42902: no certificate available for '172.18.0.3'"}
project-wiki-1  | {"level":"debug","ts":1724261857.9532342,"logger":"events","msg":"event","name":"tls_get_certificate","id":"dd34f5a9-a891-4047-b577-ccb6c8035c76","origin":"tls","data":{"client_hello":{"CipherSuites":[27242,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"ServerName":"","SupportedCurves":[14906,25497,29,23,24],"SupportedPoints":"AA==","SignatureSchemes":[1027,2052,1025,1283,2053,1281,2054,1537],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[56026,772,771],"RemoteAddr":{"IP":"192.168.65.1","Port":29309,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":31415,"Zone":""}}}}
project-wiki-1  | {"level":"debug","ts":1724261857.9533072,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"}
project-wiki-1  | {"level":"debug","ts":1724261857.9533222,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.65.1","remote_port":"29309","server_name":"","remote":"192.168.65.1:29309","identifier":"172.18.0.3","cipher_suites":[27242,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"cert_cache_fill":0.0002,"load_or_obtain_if_necessary":true,"on_demand":false}
project-wiki-1  | {"level":"debug","ts":1724261857.9535067,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.65.1:29309: no certificate available for '172.18.0.3'"}
project-wiki-1  | {"level":"debug","ts":1724261857.9537725,"logger":"events","msg":"event","name":"tls_get_certificate","id":"f71082a6-b47d-492b-bd54-8a4f2e4f3e23","origin":"tls","data":{"client_hello":{"CipherSuites":[60138,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"ServerName":"","SupportedCurves":[39578,25497,29,23,24],"SupportedPoints":"AA==","SignatureSchemes":[1027,2052,1025,1283,2053,1281,2054,1537],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[23130,772,771],"RemoteAddr":{"IP":"192.168.65.1","Port":18000,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":31415,"Zone":""}}}}
project-wiki-1  | {"level":"debug","ts":1724261857.9538822,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"}
project-wiki-1  | {"level":"debug","ts":1724261857.9539733,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.65.1","remote_port":"18000","server_name":"","remote":"192.168.65.1:18000","identifier":"172.18.0.3","cipher_suites":[60138,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"cert_cache_fill":0.0002,"load_or_obtain_if_necessary":true,"on_demand":false}
project-wiki-1  | {"level":"debug","ts":1724261857.9541323,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.65.1:18000: no certificate available for '172.18.0.3'"}
project-wiki-1  | {"level":"debug","ts":1724261857.9566464,"logger":"events","msg":"event","name":"tls_get_certificate","id":"e625acac-e829-4c03-953a-2c5cff30c07e","origin":"tls","data":{"client_hello":{"CipherSuites":[14906,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"ServerName":"","SupportedCurves":[2570,25497,29,23,24],"SupportedPoints":"AA==","SignatureSchemes":[1027,2052,1025,1283,2053,1281,2054,1537],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[27242,772,771],"RemoteAddr":{"IP":"192.168.65.1","Port":63737,"Zone":""},"LocalAddr":{"IP":"172.18.0.3","Port":31415,"Zone":""}}}}
project-wiki-1  | {"level":"debug","ts":1724261857.9567192,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.18.0.3"}
project-wiki-1  | {"level":"debug","ts":1724261857.956738,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"192.168.65.1","remote_port":"63737","server_name":"","remote":"192.168.65.1:63737","identifier":"172.18.0.3","cipher_suites":[14906,4865,4866,4867,49195,49199,49196,49200,52393,52392,49171,49172,156,157,47,53],"cert_cache_fill":0.0002,"load_or_obtain_if_necessary":true,"on_demand":false}
project-wiki-1  | {"level":"debug","ts":1724261857.956848,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.65.1:63737: no certificate available for '172.18.0.3'"}

Ahhhh. You don’t actually have the Caddy container’s port 80 open, just 31415 (and 5000). Sorry, I should’ve picked up on that and asked for curl -kvL https://10.37.145.182:31415 instead, as HTTP->S redirects won’t be functional without port 80.

This is interesting and I might have to confer with colleagues because my own knowledge of what’s happening behind the scenes re: Docker networking and ClientHello is a little lacking.

In the meantime, could you run that updated curl -kvL https://10.37.145.182:31415 command and let me know what it returns?

1 Like

I am still new to all of this but I should have realized this haha. This is a server that was developed years ago and I inherited the project so forgive the strange port numbers.

Here are the results of curl -kvL https://10.37.145.182:31415

# curl -kvL https://10.37.145.182:31415
*   Trying 10.37.145.182:31415...
* Connected to 10.37.145.182 (10.37.145.182) port 31415 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

TL;DR: You shouldn’t use an IP site address for HTTPS inside Docker.


So, it turns out it’s not actually that complicated. There’s not (much) Docker nonsense going on, no crazy userland proxy stuff or strange networking implementation details. It’s pretty much just plain routing; Docker is forwarding packets sent to the exposed port on your host onwards to the container. Perfectly good and normal.

Well - the quirk here that’s causing issues for you is that IP addresses are NOT permitted to be used in Server Name Indication (SNI).

Caddy relies on SNI to determine what site a client is trying to connect to, in order to figure out which HTTPS certificate to offer them. In lieu of IP SNI, Caddy uses the IP address the packets are being sent to in order to determine which IP hostname to select for the certificate, since that mostly makes sense.

Since you’re routing packets to a container with its own IP address, though, Caddy sees those packets incoming to the container IP (and not the host’s IP), looks for a certificate for the container IP, and comes up empty since it wasn’t configured. When Caddy doesn’t have a certificate for a requested site, it returns no certificate - effectively breaking the HTTPS connection process - rather than leaking information about what other sites are handled by your server by returning a random one.

Good news is, this goes away the moment you use actual DNS names and SNI can function normally. You said you got certificates from Digicert, which I can only assume are for real DNS names, so once you start actually using those names instead of an IP address you’ll be golden.

I should also mention that there are default_sni and fallback_sni global options that could be used to configure what site Caddy selects for when SNI is questionable, but I’d strongly recommend just swapping to DNS names, even if you have to use internal ones for test deployments.

2 Likes

Ok I appreciate that feedback! That makes sense to me. I’ll try an internal DNS name to test with.

Would this require changing the IP address I have down in the caddyfile to a DNS name instead?

That will be necessary, so that when a client connects using the new internal DNS name for Host/SNI, Caddy recognises that request and handles it correctly.

1 Like

Just a little update, I had to go through some admin to get a DNS name to test on. I believe my certificates are now invalid because of IP addresses we had to change. I will give an update on this once I get new certificates to see if it worked!

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