Auto ssl on any domain

1. The problem I’m having:

I want anyone to be able to add a domain to my site by pointing their domains to my server. I saw caddy can automatically issue SSL, but when I tried (by using an astrix in caddyfile) i got a warning along the lines of “no OCSP stapling for [*]”. How would I go about this? It works fine if I use a single domain, but I need an infinite amount.

2. Error messages and/or full log output:

Running systemctl status caddy outputs:

Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.1616285,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.161742,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["*"]}
Nov 25 05:25:00 main caddy[12760]: {"level":"warn","ts":1700889900.1621225,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [*]: no OCSP server specified in certificate","identifiers":["*"]}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.173391,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/var/lib/caddy/.local/share/caddy"}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.1741946,"logger":"tls","msg":"finished cleaning storage units"}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.1745284,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40004f2100"}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.177789,"logger":"pki.ca.local","msg":"root certificate is already trusted by system","path":"storage:pki/authorities/local/root.crt"}
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.178345,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Nov 25 05:25:00 main systemd[1]: Started Caddy.
Nov 25 05:25:00 main caddy[12760]: {"level":"info","ts":1700889900.1823292,"msg":"serving initial configuration"}

3. Caddy version:

v2.7.5

4. How I installed and ran Caddy:

I installed it by following the docs (copy and paste) and than used an example a friend showed me along with verification from the docs on setup

a. System environment:

Ubuntu 22.04 on Oracle Cloud free tier

b. Command:

systemctl restart caddy

c. Service/unit/compose file:

d. My complete Caddy config:

* {
        reverse_proxy localhost:8080
}

You’re looking for On-Demand TLS:

This doesn’t work because * only matches a single label of the domain (a label is parts between the dots), so it would only match localhost for example (single label) and not example.com (two labels).

Wildcards like this are only useful for wildcard certs, but that’s not the same thing as you’re looking to do. You should use a catch-all like https:// { (read the docs above).

Ok, thank you so much! Im new to caddy and wasn’t sure what I was looking for :smile:

this fixed my current issue of tls, but a new on has arisen. I want to reverse proxy the user to 127.0.0.204:8080 (another server on my internal network) but it seems to be redirecting back to itself on port 8080 (as if i did 127.0.0.216:8080 as the redirect, which is its own internal ip). Is it possible to do a reverse proxy to another server in the same network?
My current config is:

{
    on_demand_tls {
        ask      http://localhost:5555/
    }
}

https:// {
         tls {
            on_demand
         }
         reverse_proxy 127.0.0.204:8080
}

That’s a problem with your upstream app, not with Caddy.

I can’t help with that problem without seeing any logs and an example request curl -v.

so caddy is able to direct to another internal ip? could there be any caching that would be showing me the wrong page? i just have two simple node servers serving “I am server 1” and “I am server 2”, and it continues to show “I am server 1” no matter what (I checked that I have it running on the correct server with curl, they both output whats expected when I curl their internal ip’s)

Connecting to another internal IP is the primary usecase of reverse_proxy. There’s no built-in caching.

Again, please show your logs and example requests. I can’t do anything to help without seeing evidence of the actual problem.

Sorry, I’m new to networking and didn’t know that there was a difference between 127.x.x.x and 10.x.x.x. After fixing that issue everything seems to be working like intended, thank you so much for your help with everything!

1 Like

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