Wordpress Multisite Certificates

[jsvde]

Hey all,

I’m currently running caddy as a docker container in front of dockerized wordpress multisite install.
Everything works great so far!

Since LetEncrypt does not support wildcard certificates yet, I use the following options in my Caddyfile:

www.example.com {
  redir example.com{uri}
}

 example.com, *example.com {
    ...
    tls {
        max_certs 20
    }
   #wordpress settings like fastcgi yadda yadda
}

As I stated this works quite well, but I did read, that it’s not recommended to create OnDemand certificates on a broader scale and I’m searching for a way to dynamically insert new specific subdomains to the caddy configuration when created with WP multisite.

Another thing is the domain mapping. For every external domain I map to wordpress I have to add a block like:

www.anotherdomain.com {
   redir anotherdomain.com{uri}
}

to the caddyfile. After that ‘anotherdomain.com’ has to be added to the block with all the wordpress settings.

Are there any solutions for this kind of ‘problem’? I thought maybe there is a way to import a dynamic list of domainnames which are mapped to one config block like this:

import ('domainnames.txt'){
   tls ...
   fastcgi ...
}

And just append new domains from wordpress and the domain mapping to the domainnames.txt file - but that’s just thinking out loud…

I’m really grateful for any kind of suggestions and tips! Thank you in advance and keep up the great work on Caddy!

Cheers Julian

[Whitestrake (Matthew Fay)]

Hi @jsvde, welcome to the Caddy community.

@jsvde

Are there any solutions for this kind of ‘problem’? I thought maybe there is a way to import a dynamic list of domainnames which are mapped to one config block like this:

Looking at the import directive: https://caddyserver.com/docs/import

Its contents will replace this line, as if that file’s contents appeared here to begin with.

OK, so can we structure a file such that it contains a list of domains, which upon being imported, will result in valid Caddyfile syntax? There’s a few things to keep in mind, from the Caddyfile spec: The Caddyfile — Caddy Documentation

A Caddyfile with only one entry may consist simply of the label line(s) followed by the definition on the next line(s) … However, a Caddyfile with more than one entry must enclose each definition in curly braces { }. The opening curly brace { must be at the end of the label line, and the closing curly brace } must be the only token on its line:

So it looks like we’ll have to change how we approach this depending on whether or not you need to have multiple sets of labels. I’m going to assume we DO want multiple sets of labels, because taking the multiple-entry route also works with a single entry anyway. Looking back at the spec again to find out what we need to make our domain list look like:

If many labels are to head a block, the labels may be suffixed with a comma. A comma-suffixed label may be followed by a newline, in which case the next line will be considered part of the same line:

label1,
label2

Alright, this looking conducive to some kind of dynamic list generation. It’s just a comma+newline-delimited list of labels. Easily scripted. But we also know that opening a server block, { has to be at the end of the label line. So our domains.txt will have to look like this:

label1,
label2 {

Simple enough if we’re scripting it. Comma+newline delimited join of all domains, then add { at the end. So if our domains.txt looks like that, and our Caddyfile looks like this:

import domains.txt
   # Config here
}

We should have a valid Caddyfile, with a dynamic list.

Personally, I’d like to see the opening brace in the Caddyfile itself, because I find unmatched braces obnoxious. So just to make it neater, I’d probably skip adding { in the dynamic list, end with a comma instead, with a Caddyfile like this:

import domains.txt
:80 {
  # Config here
}

Caddy would treat the Caddyfile like it was this:

label1,
label2,
:80 {
  # Config here
}

You might not want to use this as the default for :80 though, so you could find some other dummy label that’ll never be relevant if you like (just make sure it’s http: or :80 though so Caddy doesn’t try to get a cert for it).

---

As an aside with regards to the redir to canonical non-www, doesn’t WordPress handle this by default? I thought it issued canonical redirects to whatever its URL was set to. Maybe it’s different in multisite?

[jsvde]

Hi @Whitestrake and thank you for the welcome and your great and detailed answer!

I feel kind of stupid for not searching for “caddy import” since I mentioned it myself in the question, I was just looking for “dynamic domains” and alike.

Reading the import docs, you answer makes perfect sense, thank’s again!

I will go for the solution of having my primary domain without www after the import statement containing all available domains.

import domains.txt
example.com {
   ...
}

I’m not sure how wordpress handles the domain redirect but will look into it.

Cheers Julian