I have a multisite install that has a small number of subdomain-based subsites. I found myself in a situation today where I needed to quickly restore the site from the previous provider (RunCloud) to a new Webinoly install.
DNS is managed via client's internal IT team and we don't have fast access to make DNS changes, but luckily I had used a floating IP when initially setting up the sites so I was able to remap the floating IP to the new server.
What I DIDN'T have access to, however, was the ability to set up wildcard domain config by doing the DNS challenges. Instead, I manually mapped the domains to do normal domain-based validation:
sudo site sub.domain.com -parked=domain.com
sudo site sub.domain.com -ssl=on -root=domain.com
When taking these steps, a few things happened that prevented it from working:
1) Nginx config was updated to indicate that SSL certs were already present for subdomain when in fact they weren't. For this reason, Nginx wouldn't reload and was throwing error messages.
2) Nginx config files weren't generated correctly for the subdomain URL. In the server blocks near the top of the file, Webinoly generated the domain in the format sub.sub.domain.com instead of sub.domain.com. This prevented the site from being accessible at all, with or without SSL.
3) When I ran the -ssl command, I'd get an error message saying "SSL has already been set up for this domain" but that was not true. There were no certs installed. I had to first run sudo site sub.domain.com -ssl=off to correct this.
I know this is a bit of an edge case, but I've certainly had other situations where we needed to map some kind of a subdomain to a multisite install, and it won't always be a subdomain of the top level domain the network is hosted on (i.e. not a situation where a wildcard cert would help).
It's entirely possible I was doing something wrong, but wanted to point out my experience in case it's something that needs investigated.
