Question Synology DDNS wild card cert w/LE

[Telos]

I'm nearing my renewal date for aaa.synology.me, and want to change that to a wild card... do I enter *.aaa.synology.me as the domain name, and assume that aaa.synology.me falls under the wild card, or ... do I enter *.aaa.synology.me as SAN with aaa.synology.me in the domain field?

Has anyone set up a Synology DDNS using w/DSM 6.2.2? Or is 6.2.3+ required?

 

[Rusty]

6.2.3 is the DSM version that supports wild card:

Added support for Let's Encrypt wildcard certificates for Synology DDNS.​

​

Considering that I haven't tried it, my guess is that you create *.aaaa.synology.me.

 

[Telos]

6.2.3 is the DSM version that supports wild card

If I'm stuck using 6.2.3, I'll request the cert using my backup NAS and then export/import it into my primary NAS (which will remain at 6.2.2 for now).

Exporting gives 3 files... cert.pem, chain.pem, privkey.pem. Importing has three fields...

Private key: presumably for privkey.pem
Certificate: presumably for cert.pem
Intermediate Certificate (optional): What is this? chain.pem? [I can't locate "chain.pem" on mr. google]

 

[Rusty]

LE doesn’t issues an intermediate one

 

[one-eyed-king]

A wildcard certificate for *.sub.domain.tld, does not cover sub.domain.tld. I would use the non star version as CN and the star version as SAN.

The intermediate certificate usualy consists of one or more certificates of intermediate CA's up to a root CA. Sometime your find the file fullchain.pem, which is the cert.pem (the public part of your certificate) + chain.pem (the public part of the intermediate CA's certificate). Normaly you want to use fullchain.pem, rather then just the cert.pem. LE is an established CA and as such may not require intermediate CA's.

 

[akahan]

LE doesn’t issues an intermediate one

Then what's chain.pem?
I have numerous LE certs. If I "export" one of them from a Diskstation, I get three files: the private key, the cert, and chain.pem, which I assume is the certification chain, or intermediate cert.

 

[one-eyed-king]

Usualy chain.pem should hold all intermediate certificates required to validate the certification chain. The chain for LE realy is short. For me "DST Root CA X3" is the Root-CA. The chain.pem should include the certificate for the signing CA "Let's Encrypt Authority X3" (the one that actualy created the key+cert for the domain)".

With Crome, it is quite easy to check the certificate chain. Left to the URL-bar, there is a lock-icon, which if clicked brings up a contxt menu; select "certificate" to open a new window (not sure if this works on a non Windows 10 Sytem as well. ..). Change to the "certification chain" tab and see the chain of trust. The top starts with the Root-CA, follwed by the signing CA as intermediate CA and finished by the actual domain certificate at the buttom. The whole chain need to be known and valid in order to validate a certificate; this is why using the fullchain.pem helps the client to get all, except the Root-CA's certificate to verify the actual domain's certificate (i hope this makes sense).

 

[akahan]

 

[one-eyed-king]

You should be able to check the content of chain.pem (and the others of course as well)
Try openssl x509 -in chain.pem -text to see details. the relevant part is somewhere at the beginning. You should see that it actualy includes the "Let's Encrypt Authority X3". The fun part is: your browser just needs to have the "DST Root CA X3" in it's truststore. Because of that, it will trust "Let's Encrypt Authority X3", even if it was provided by the web server through the fullchain.pem - then it will trust your domains certificate transitivly as well.

If a certificate is considered valid is realy highly dependend on the application/browser/programming language, as each provides its own default truststore; there is no guaranty that different default truststores include the same Root-CA's. Even if you buy a certificate from a commercial CA, there is no guranty that it's build into any of those truststores (commodo certificates). LE usualy is delivered with default truststores - even on devices like tv's - and therefore trustworthy by default

 

[Micky]

6.2.3 is the DSM version that supports wild card:

Added support for Let's Encrypt wildcard certificates for Synology DDNS.​

​

Considering that I haven't tried it, my guess is that you create *.aaaa.synology.me.

So why is this bound to Synology's own domain and why can't I use my domain name to acquire a wildcard certificate?

 

[Rusty]

Probably because they don’t support le wild cert la for domains that they don’t control and/or own

 

[Telos]

I have 2 NAS... one with DSM6.2.3, the other w/6.2.2 (which I'm not ready to upgrade). Each NAS has a unique Synology DDNS.

I thought I could create an LE wild card for the 6.2.2 NAS, using the 6.2.3 NAS, but this failed.

I'm curious if there is a way to trick this out (both are on the same LAN).

While writing this post, I thought I might forward port 80 to the 6.2.2 NAS while forwarding port 443 to the 6.2.3... and try again. Maybe that's crazy.

Any thoughts? Or must I wait until I upgrade the 6.2.2 NAS?

 

[akahan]

How did you fail? You should be able to forward ports 80 and 443 to the 6.2.3 NAS, and use that NAS to to create the certificate. Then, once it has the certificate, export the certificate, import it onto the 6.2.2 NAS, and change the port forwarding back to however it was before. At what point do you get stuck?

 

[Telos]

How did you fail? You should be able to forward ports 80 and 443 to the 6.2.3 NAS, and use that NAS to to create the certificate.

I did all that. I just got connection failed. I presumed that it realized that the 6.2.3 NAS wasn't registered for the DDNS.

However I did have an active cert for the same DDNS domain located on the 6.2.2 machine, so maybe it could not create a new one without deactivating the old. IDK. So I changed machines and did a cert replace (I had to update a SAN) and everything worked as expected (but no wild card).

Or maybe it was because the 6.2.3 has a default cert for its DDNS.

There's wasn't much info on the error window.

Have you done this?

 

[akahan]

Are both diskstations on the same local network, sharing the same WAN address (just at different ports)? If so, the DDNS address would just be the WAN IP address; in other words, using the DDNS address for one Diskstation would be exactly the same as for the other. So you (and lets encrypt) should be able to reach Diskstation #1 by using Diskstation #2's DDNS address, just w/different ports.

And yes, I do this ALL THE TIME, or the equivalent: I use one of my diskstations (the one to which ports 80 and 443 are directed) to get a Lets Encrypt cert, and then I export that certificate, and then import it onto five other diskstations and my Synology router, all of which are on the same LAN, and share the same WAN IP address.

 

[Telos]

And yes, I do this ALL THE TIME, or the equivalent: I use one of my diskstations (the one to which ports 80 and 443 are directed) to get a Lets Encrypt cert, and then I export that certificate, and then import it onto five other diskstations and my Synology router, all of which are on the same LAN, and share the same WAN IP address.

Yes, it's all the same LAN w/different IPs, and the reason why I thought this would work.

Like you, I too have moved a cert from the NAS associated with the NAS2 DDNS, to NAS1.

Yet, registering an LE cert for NAS1's DDNS, using NAS2 isn't the same as exporting/importing LE certs across to different NAS (which you have described). I'm thinking that the machine itself is involved with the verification/authorization, and since NAS2 can't account for the NAS1 DDNS domain, the process falters.

I could be wrong, but it is not working here.

 

[akahan]

If that is the case, though, couldn't you temporarily set NAS2 up for the desired DDNS, fetch the cert, and then switch NAS2 back again?

 

[one-eyed-king]

Uhm, don't wildcard certificates still require dns01 challenge for verfication?
Thus, synologies client has to insert a txt record via the dns api for the domain.
The LE-client usualy has to check for existance and value of such a txt record.

Maybe this explains, why Synology only support wildcard certificates for their own domains.
Otherwise they would need to add support for a broad range of dns-api providers...

 

[akahan]

I think we are talking here entirely about certs for Synology domains, though. That is, the discussion I was responding to was the one triggered by Telos' post #12, where he said: "Each NAS has a unique Synology DDNS."

I agree that the process would be entirely different for wildcard domains for NON-synology domains...those can't be obtained through Synology's GUI, but have to be gotten by some other means and then imported into the Diskstations.

 

[one-eyed-king]

My response was triggered by the whole port 80/443 discussion. It gave the impression that those ports would be involved in the verification processes when creating a wildcard certificate; they are not.