The answer to your question is: it depends upon how you intend to prove that you control the (sub)domain name(s) in question. If you're using http-01 challenges, you need A records that point to public IP addresses. If you're using dns-01 challenges, you need TXT records. In either case, the records themselves need to be publicly accessible. CNAME records can be used to "redirect" the challenges, but ultimately the same rules apply.
That depends entirely on the authentication method chosen.
If you are going to use HTTP authentication, then yes, LE must resolve each name to an IP and be able to access that IP via port 80 (HTTP) to complete the challenge.
If you are going to use DNS authentication, then, no, LE will only check entries in the DNS zone.
[which do not require the names to have IPs].
Guess I'll have to check further with Synology how they're doing it. Their Rel. notes are claiming I can add in SAN's into an LE request.
Your responses seem to indicate I will nevertheless need to add in public records for each sub-dom. I'll have a read and may come back.
At this point I already have 1 x A for a sub and 1 x CNAME for a sub I want to use in the same cert. What I don't have publicly is records for the 2 other subs I want to use on the same cert. And your responses give me a little cause for concern.
As a "trick" you can first prove control of all the public subdomain names using http-01 challenges (with A records), letting all the private ones fail. Then you can prove control of the private subdomain names using dns-01 challenges (with TXT records) to complete. The Let's Encrypt server caches the successful subdomain name authorizations across failed orders.
I am hoping to use the std Synology DSM interface to have them deal with it all rather than install acme.sh and go through that process. Synology seem to be stating their most recent DSM updates handle it all automatically.
I'll see what they respond with first, before digging and in going the acme.sh route.
You could provide that one IP to the Internet for all the names and have your device get a SAN cert for it.
And then provide a completely different set of IPs internally on your local LAN.
But the question here is: If the cert will be on the Synology, how will any of those other named devices use it?
1 public IP running mail server and vpn server. 2 sub-domain names, one for each.
The other 'internal' / 'secret' names would be registered in internal DNS so they could be referred to internally only. The other names are essentially ... either aliases for the Synology or the Synology can reverse proxy the cert calls to whichever other hosts are required.
1.me.com is a public (and internal) DNS record pointing to the Synology (public v private IPs). 2.me.com is CNAME pointing to 1.me.com - public.
3 & 4 are internal DNS names each pointing to the Synology which internal hosts would use.
to use either as an RP cert server, I just need to point to say 4.me.com internally which will RP the cert call to 7.me.com.
I still don't get the secure design.
It seems all requests will have to go through the Synology [which is connected to the Internet].
And none of the other endpoints will actually have a cert installed to secure any connections.
The Synology runs mail and VPN - connected publicly. They're the only sub. names I want public.
Any other internal appl., I am happy to host thru the Synology for secure connections as they are not accessed externally.
But your earlier responses seem to say that for every sub-domain SAN I want on the one LE cert., I have to have at very least, a public TXT record for it, right?
p.s. Just to clarify, internally the Synology is connected to via an internal subnet on separate NIC. And from externally via a diff. untrusted subnet on a diff. NIC.