Using caddy for internal dns

0. What I want to do

I have a VPS , which is docker host , running on it application docker container

version: '3.3'
services:
  phpmyadmin_tests:
    image: phpmyadmin/phpmyadmin:5.0.2
    container_name: phpmyadmin_tests
    hostname: d-padmn.innoyapps.com
    restart: always
    networks:
       - d-my-network
networks:
   d-my-network:
     external: true

caddy is deployed via the following docker-compose:

version: "3.7"
services:
    internal-caddy:
       image: caddy:latest
       restart: always
       container_name: internal-caddy
       hostname: internal-caddy
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile
         - ./data:/data
       networks:
         - d-my-network
networks:
   d-my-network:
     external: true

important note is that the hostname : d-padmn.innoyapps.com is totally internal and resolvable inside the docker host.
what I want , is to implement caddy for tls/ssl termination so it can be accessible via https://d-padmn.innoyapps.com

1. The problem I’m having:

I’m getting error about that domain does not exist , I wonder if I can use Caddy to have https for internal domain names

2. Error messages and/or full log output:

2024-01-17T08:41:32.500376768Z ERR | ts=1705480892.5001667 logger=tls.issuance.acme.acme_client msg=challenge failed identifier=d-padmn.innoyapps.com challenge_type=tls-alpn-01 problem={"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for d-padmn.innoyapps.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for d-padmn.innoyapps.com - check that a DNS record exists for this domain","instance":"","subproblems":[]} 
2024-01-17T08:41:32.500402398Z ERR | ts=1705480892.5002303 logger=tls.issuance.acme.acme_client msg=validating authorization identifier=d-padmn.innoyapps.com problem={"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for d-padmn.innoyapps.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for d-padmn.innoyapps.com - check that a DNS record exists for this domain","instance":"","subproblems":[]} order=https://acme-v02.api.letsencrypt.org/acme/order/716970867/237316218356 attempt=1 max_attempts=3 
2024-01-17T08:41:34.554773940Z ERR | ts=1705480894.5539649 logger=tls.issuance.acme.acme_client msg=challenge failed identifier=d-padmn.innoyapps.com challenge_type=http-01 problem={"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for d-padmn.innoyapps.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for d-padmn.innoyapps.com - check that a DNS record exists for this domain","instance":"","subproblems":[]} 
2024-01-17T08:41:34.554798474Z ERR | ts=1705480894.553998 logger=tls.issuance.acme.acme_client msg=validating authorization identifier=d-padmn.innoyapps.com problem={"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for d-padmn.innoyapps.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for d-padmn.innoyapps.com - check that a DNS record exists for this domain","instance":"","subproblems":[]} order=https://acme-v02.api.letsencrypt.org/acme/order/716970867/237316223636 attempt=2 max_attempts=3 
2024-01-17T08:41:34.554804726Z ERR | ts=1705480894.5540254 logger=tls.obtain msg=could not get certificate from issuer identifier=d-padmn.innoyapps.com issuer=acme-v02.api.letsencrypt.org-directory error=HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: NXDOMAIN looking up A for d-padmn.innoyapps.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for d-padmn.innoyapps.com - check that a DNS record exists for this domain 
2024-01-17T08:42:07.878507218Z ERR | ts=1705480927.8783238 logger=tls.obtain msg=could not get certificate from issuer identifier=d-padmn.innoyapps.com issuer=acme.zerossl.com-v2-DV90 error=[d-padmn.innoyapps.com] solving challenges: authz https://acme.zerossl.com/v2/DV90/authz/FpD_Gc8negDGkXAz_RErjQ has unexpected status; order will fail: invalid (order=https://acme.zerossl.com/v2/DV90/order/KxAnbDAy-rk_OU-Q7ANDpA) (ca=https://acme.zerossl.com/v2/DV90) 
2024-01-17T08:42:07.878559076Z ERR | ts=1705480927.878399 logger=tls.obtain msg=will retry error=[d-padmn.innoyapps.com] Obtain: [d-padmn.innoyapps.com] solving challenges: authz https://acme.zerossl.com/v2/DV90/authz/FpD_Gc8negDGkXAz_RErjQ has unexpected status; order will fail: invalid (order=https://acme.zerossl.com/v2/DV90/order/KxAnbDAy-rk_OU-Q7ANDpA) (ca=https://acme.zerossl.com/v2/DV90) attempt=1 retrying_in=60 elapsed=36.916152039 max_duration=2592000 

3. Caddy version:

4. How I installed and ran Caddy:

v2.7.6

a. System environment:

docker compose ( both app and caddy )

b. Command:

docker compose

c. Service/unit/compose file:

d. My complete Caddy config:

{
        email info@innoyadev.fr
}
d-padmn.innoyapps.com {
        handle {
                reverse_proxy d-padmn.innoyapps.com:80
        }
        log {
                output file /var/log/caddy/d-padmn.innoyapps.com-access.log
                format json
        }
}

5. Links to relevant resources:

Yes, you can use tls internal to enable Caddy’s internal CA, which will issue certs for any domain. But those certs will not be trusted unless you add Caddy’s root CA cert to each client that will want to connect to it. tls (Caddyfile directive) — Caddy Documentation

You’re missing ports, so nothing can reach Caddy. Unless I misunderstand what you’re trying to do here.

See our Docker Compose recommendations in the docs Keep Caddy Running — Caddy Documentation

thank you @francislavoie
the idea behind is that I’m using already Caddy to reverse proxy public domain names , and ports of course are published there ( 80 and 443 )
domain names are pointed to my VPS IP , so Caddy will catch the requests and route them correctly to the docker containers.
What I want to achieve on top of this , is that I have implemented Zero-trust network ( Twingate ) , where I can access some docker containers only via the Twingate network
the situation now is that I can access only http and not https , that is why I thought about caddy can terminate tls for these internal access only via Twingate

in Twingate i’m setting the internal docker containers hostname to target them in browsers
so i hope it is more or less explained what is the goal here

So you’re saying you have two Caddy instances, one on your VPS and one in your LAN, with a tunnel in between?

Then your LAN one should use http:// as a prefix to site addresses so it doesn’t set up HTTPS, then your VPS one can proxy to it transparently.

no , mainly there is one instance of CADDY which in my VPS
I added twingate so I can assure that some of the docker containers can be accessible only vie twingate network.
that is why I thought about another instance of caddy which can be totally internal in my VPS to handle https for those are accessed via Twingate network

My answer still applies. Twingate as far as I understand is still providing a tunnel between your Caddy instances.

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