A discussion on DSM and LE certs.

[namedNik]

Hi Peoples,

So, I've read the various threads and recognise this comes up on a regular basis; and while I may have missed it, I don't recall anywhere seeing the answer to the questions I have; and Synology support are .............. well, ............... let's just say, being less than helpful.

The Short Version:

While attempting to create an LE cert using the DSM wizard interface, when the 'process' as a whole checks DNS records to confirm/verify IP, WHICH process is looking at WHAT view of DNS and WHERE is it looking to find the information that tells it which view of DNS to look at?

The Long Version:

Rather than use @Rusty's 'blackvoid.club' process or NeilPang's acme.sh script, I am happy enough to just use the DSM interface for a cert. I really only want/need two sub.s (1 for a mail server and 1 for a VPN endpoint). If I ever really need to go down to the wildcard level, I'd prolly use 'acme.sh'. But for now,.... I'm ok with 80 & 443 being open. I figure Synology HAVE to have sufficient protections in place for 80 - and I don't really have anything running on there other than a couple of apps.

So, with that said, let's go with I own the domain 'acme'com'.

There are 3 DNS views of acme.com (Public, NAS WAN NIC subnet, and NAS LAN NIC subnet) - so an untrusted subnet setup.

Public DNS has: mail.acme.com A record > fixed IP and endpoint.acme.com CNAME > mail.acme.com.
NAS WAN has: mail.acme.com A record > fixed IP and endpoint.acme.com CNAME > mail.acme.com. But naturally, they are on a private subnet (172.16.x)
NAS LAN _also_ has: mail.acme.com A record > fixed IP and endpoint.acme.com CNAME > mail.acme.com. And they are on a different private subnet (192.x)

Yet, when I try to create an LE cert, I get the very basic std error: "Unable to connect to Let's Encrypt" (paraphrasing here - can't rememeber exact now).

I know 80 & 443 are open and connect to the NAS as I actually have another LE cert defined and running via the DSM interface for a.n.other host name and domain pointing to a VM device in the NAS via RP. So you'd think I'd be cluey enough to figure out just WTF is going wrong.........

Apparently not! So here I am.

Synology support states:

The reasons that certificate usually fails boils down to three things:
1. Port 80 is not forward to port 80 and also not pointed to the NAS.
2. The domain name and also the domain in the Subject Alternative Names does not point to the NAS WAN IP address.
3. NAS is not up to date.

I know 80 is open and works. DSM is running DSM 6.2.3-25426 Update 3, so it's uptodate. Which only leaves 2.


So Questions:

1. WHAT process is checking WHICH view of DNS when looking to verify the domain or IP when attempting to create the cert?
2. Is the NAS using the DNS view registered in Control Panel > Network > General? Or something else?
3. Does the domain for which I'm trying to create the cert HAVE to have a 'root' record defined? As publicly I have the root parked and WAN/LAN Views have no root A record defined.
4. Finally, I would expect whichever process is attempting to create this bloody cert, to be run by root, but possibly not. So in needle-in-haystack mode, I ask; I recently enabled 2FA for Admin accounts. Could that possibly be the problem?

Troubleshooting this wouldn't be so much of an issue as each and every combo just takes time, but LE's 5 attempts / hour limit is a real pain in the .... and I don't' know if after <x> attempts, whether they just block an IP/account/email addr. or whatever?

Are you the Collective able to offer some insight pls?

 

[Rusty]

I don't' know if after <x> attempts, whether they just block an IP/account/email addr. or whatever?

They won’t.

Detailed explanation no doubt. Sorry for my short answer/question then but have you checked the /var/log/messages file?

In it you will have a detailed error on the matter and will get exact return of a potential problem.

Let’s start from there.

 

[namedNik]

/var/log/messages

Cheers @Rusty.

I have in the meantime managed to extract the actual cmdline 'syno-letsencrypt' call from Synology and while not exactly the "detailed error" you suggest, /var/log/messages does correspond with the error coming from the cmdline.

Long story short, what was stopping it was the DNS CAA records I had set up in defence of the previous CA I was using. So, despite not achieving the answers to my questions, I have a resolution.

..... So fecking simple, when you work it out.