Let's Encrypt Certificate Renewal

[WST16]

Country - never thought of that; I will look into it.

Most likely the firewall is blocking it. You’ll never know where it’s coming from. My suggestion is to add a reminder on your calendar to renew manually 5-10 days before expiration. It’s not worth opening the ports for the whole world just for that one thing.

 

[Rusty]

Most likely the firewall is blocking it. You’ll never know where it’s coming from. My suggestion is to add a reminder on your calendar to renew manually 5-10 days before expiration. It’s not worth opening the ports for the whole world just for that one thing.

I agree. Running with DNS validation is a lot better but if that is not an option then an on/off solution would do the trick.

 

[NSquirrel]

Thanks WST16: good point. I will still steadily investigate further, e.g. logs, but what you say may be best.

 

[WST16]

To clarify, what I meant above by saying that you’ll never know where it’s coming from, is a reference to Let’s Encrypt connection request, otherwise we can add an “allow” for it in the firewall if we consider the risk acceptable (for example, hypothetically for me I’d be more inclined to add an “allow” for a country like Switzerland or Singapore but not China, because of size and other factors). However, the request might come from any Let’s Encrypt server around the world, so it’s hard to predict.

So I don’t mean that you’ll never be able to find out why whats happening is happening. Thought of clarifying it because when I re-read it I thought it might be understood in such a way (my fault)

 

[NSquirrel]

Thanks WST16: I do not think that I am blocking any country as far as I know. I can renew manually, although renewal may come from anywhere.

I checked my ports with a utility from PC to NAS and ports seem OK. Ports in router seem OK, checked via external web-based utility.

I have found how to get to the logs mentined above. I started via Telnet to the logs, before realising that I could get them via Support Centre, which is somewhat easier and safer. Telnet gives an interesting view inside the NAS likely to cause nightmares not being a LINUX user. Useful to know how to access the 'insides'; I just have to be careful, obviously.

I may have to continue slowly, if not come to a stop, as I realised that I won't see another need for an automatic renewal for another 60 or so days, by which time I may well have cleared the problem and then inadvertantly set it back again!

 

[WST16]

I’m reflecting my own experience. That’s what it looked like to me. However, if you have 80 and 443 (or maybe just 443) open for the whole world as you say, it should renew automatically as this is my experience.

I think (not sure), when you do it manually the connection is initiated from the DiskStation, so it overcomes the firewall restrictions. I decided to renew manually a long time ago and didn’t look into it any further.

I think you’re making good progress, please keep us updated if you discover anything worth sharing. Thanks

 

[NSquirrel]

Thanks WST16:
>>when you do it manually the connection is initiated from the DiskStation, so it overcomes the firewall restrictions

I assumed that the DiskStation always tries to initiate the renewal after say 60 days rather than the Let's Encrypt server, which simply sends out the renewal reminder after 60 days. Or could it be that accessing the certificate, as part of say a VPN process, 'says' to the the DiskStation 'time to renew'? If the DiskStation initiates renewal, then a log should be full of 'tried to renew but failed' type error messages. I have not found any such messages, unless they are error code numbers. I did find logs of when I renewed manually. That suggests that the problem may be the trigger for renewal not coming in from the Let's Encrypt server, wherever that is located, and hence incoming ports rater than outgoing ports. (I hope that makes sense, even if my thoughts may be quite wrong!)

 

[one-eyed-king]

Creation and renewal is the responsibility of the letsencrypt client. Though something on the machine must trigger the execution (on linux systems typicaly a cronjob takes care to trigger the renewal), the client does it's job and finishes.

When using the http01-challange, the client will create the certificate request, then delegates the verification to LE, which tries to access http://{yourdomain}/.well-known/acme-challenge/{current token}, which then creates your certificate, which the client must fetch in some mysterious ways. This is why proper dns name resolution fory our domains and an open port 80 is required during the challenge. I would assume the LE verification will originate in the US.

 

[NSquirrel]

Thank you one-eyed-king for your explanation: A lot for me to think about.

 

[WST16]

I assumed that the DiskStation always tries to initiate the renewal after say 60 days

That’s why I said. I think.
Strangely, I was checking my DS220+ and I found that the certificate was renewed despite all the restrictions I have on the firewall. While on another DS it fails. I gave up trying to understand how it works, It’s voodoo magic to me

 

[one-eyed-king]

WST16: wildcard certificate? DNS01-challenge does not require open ports or firewall exceptions. HTTP01-chellenge does

 

[NSquirrel]

WST16: One DS renews; the other doesn't. 'Voodoo magic' seems the answer.

 

[Telos]

One DS renews; the other doesn't. 'Voodoo magic' seems the answer.

Try "Replace" and select LE, re-entering your existing domain/email info. I had to do that with one unit recently.

 

[NSquirrel]

Thanks Telos; worth a try although I wont know if it will work (i.e. auto renew) for another 60/90 days.

 

[paradeiser]

Can we pretty please just have DNS-01 challenge supported by Synology out of the box?
Actually I was quite sure it will come in DSM 7. Well…

Is there a rather easy work around to use DNS challenge on DSM?

Thanks,
marko

 

[Rusty]

Can we pretty please just have DNS-01 challenge supported by Synology out of the box?
Actually I was quite sure it will come in DSM 7. Well…

Is there a rather easy work around to use DNS challenge on DSM?

Thanks,
marko

For a custom domain, docker would be an easy way. One time setup and you are good.

 

[paradeiser]

I would need it for MailPlus Server using multiple sub-domains like imap.domain.com;mail.domain.com;… (dovecot, postfix, Webinterface)
Can you point me to some how-to documentation? There is probably no way, to assign this cert in the DSM GUI?

 

[Rusty]

I would need it for MailPlus Server using multiple sub-domains like imap.domain.com;mail.domain.com;… (dovecot, postfix, Webinterface)
Can you point me to some how-to documentation? There is probably no way, to assign this cert in the DSM GUI?

Wild card solution would cover it.

Let's Encrypt + Docker = wildcard certs

lets encrypt docker wildcard SSL certificate dsm synology cloudflare

www.blackvoid.club

 

[paradeiser]

Wild card solution would cover it.

Let's Encrypt + Docker = wildcard certs

lets encrypt docker wildcard SSL certificate dsm synology cloudflare

www.blackvoid.club

Thank you very much for the good read!
On the down-side, it would require to move all DNS entries to cloudflare and manual cert updates every 90days…

 

[Rusty]

manual cert updates every 90days

This can be automated ofc, but it is not part of the article as it's a separate element. Regarding CF hosting your domain, yes that might look like a problem, but IMHO, it was worth it.

Once you get the containers up and running you can leave them on and the cert will be renewed on the 29th day before it runs out. Also, the upside is that you do not have to have ports open (unless you use them for something else) to get the certs.

Ups and downs I guess.