Hi All,
rather than pollute the post with the std guff, I have a generic question for now.
When requesting a multi-named cert (not a wildcard cert), i.e. each extra name a sub-domain for the main domain request (e.g. alphabet.com, abc.alphabet.com, def.alphabet.com, xyz.alphabet.com), does Let's Encrypt require each of those sub-domains to have public DNS records or ...?
I would expect not, but .....
I want to be able to use the same cert for hosts with public names as well as internal names.
Welcome to the Let's Encrypt Community 
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.
Time for a bit more reading.
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.
It sounds like you might have to test the process a bit before you getting working right.
If so, you might want to see if it can use the --stating / test environment instead of production.
If you're trying to have "secret" subdomain names, you'll need to use a wildcard.
Cheers again both.
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.
Yeah.. unfortunately Synology do state clearly they don't support that other than with their own corp. DDNS service.
p.s. not so much 'secret' as known internally only. Which is realistically the same I guess.
Even secondary wildcards?
*.whatever.ddns.com
So...
internal.umbrella.ddns.com
I'll ask, but either way, I suspect whatever wildcard would have to go down the "synology.me" TLD route first. Which is no good to me as I have the TLD.
Not exactly.
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?
That is essentially the idea.
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.
But how would they actually use a cert?
If the Synology has the cert (and the reverse proxy), it implies only externally connected devices will be connected securely.
I think you may have oversimplified something beyond reason.
These services run on different ports, so they can actually use the same cert (name).
I may have the wrong idea here so, ....
the Synology will have the cert. The cert is good for 1.me.com, 2.me.com, 3.me.com and 4.me.com.
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.
agreed.
The Synology can RP multiple 443 requests to diff. hosts using a host:port combo.
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.
Correct.
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.
This is a false sense of security. If you can use the Synology to proxy to any other internal device, so can anyone (on the Internet) that can reach the Synology.
Every unique FQDN will need a TXT record added in the DNS zone to pass DNS authentication.
The dual NIC won't stop the Synology from Proxying into the unreachable LAN.