Yeah. I have exactly one public server to "work" with.
Under "Nginx on Gentoo", "wildcard", we've already noted the bugs, but above that section I see:
Follow Docker instructions
To get a wildcard certificate on this system, you'll need to run Certbot in Docker. You can do so by following these steps from our documentation.
...so, I thought, maybe that's the earlier way, it might be worth a shot...
I'm happy to read that. Away it shall now go.
Yeah; I took it to mean, "this is the way it used to work, the new way is better, but that hasn't been ported yet in every environment." Bad guess on my part.
Installation isn't the issue. Configuration is. nginx is running fine, holds multiple environments, but needs to be told to associate specific names (environments) according to a specific key, the hosting of which is...
HA! Now we come to my story! Laugh, I beg of you.
I'm doing a little project, with a small circle of people, in different parts of the country. We have a wiki we'd like to share, TiddlyWiki. I was surprised to learn that talking to this wiki -- which is, like, a wiki -- was unusual over a network. Make that network The Network? Egad! But I'd gone this far, so why stop now?
My "little project" is actually a small but growing set of projects. More than one instance of TiddlyWiki.
Fine, I thought:
https://host.name/foo/wiki/
https://host.name/bar/wiki/
https://host.name/[...]/wiki/
But, it turns out, the chosen wiki doesn't like to work that way. It really, really wants to expect:
https://foo.host.name/
https://bar.host.name/
https://[...].host.name/
Multiple instances of a single proxy web server is fine. The trouble starts to crop up when the wiki behaves like a shared instance within a single environment.
There's no way -- I have learned -- to tell TiddlyWiki to specify, say,
"/instance-A/path-X/"
"/instance-B/path-X/"
There are multiple places within the wiki where it refers explicitly to its home base as "/", and will address the OS by that hardwired name.
In my past experience it was a windfall to be able to host multiple environments withing a single "*" cert. So, doing that on a project like this was reflexive. Single system, multiple names, why bother to have more than one key?
I guess I could give each wiki instance its own unique key. Hey, they're free, w00h00! But it's nice to have an outside process (Let's Encrypt, for example) needing as few visits as possible.
New instance of the project: tell nginx to add a fresh file path (and, okay, a new A record, fine, fine, you win, TiddlyWiki);
Or:
New instance of the project: fresh nginx file path, new A record, and, conjure a fresh cert to go with the A record, deliver that, accept the response... this for a project that might not last a week and, for sure, will never involve more than half a dozen people.
