Let’s Encrypt logs?

Currently reading
Let’s Encrypt logs?

2,279
956
NAS
DS220+ : DS1019+ : DS920+ : DS118 : APC Back UPS ES 700 — Mac/iOS user
To my knowledge they’re under
/user/syno/etc/certificate
I’m looking for a log file with history of failed and successful renewals if possible.

I’m trying to check what’s going on when automatic renewal is not happening and I have to do it manually by running
/usr/syno/sbin/syno-letsencrypt renew-all

Thanks for any help.
 
Aha, thanks @Rusty. I was hoping I can find more details somewhere under the certificate directory!

Ok. Mind boggling. I’ll have to try to figure this one out!

DS118 has ports 80 and 443 forwarded to it.
DS216+II does not have ports 80 and 443 forwarded to it. Stating the obvious.

Firewalls are running on both. More blocking on the 216 in fact than the 118 and despite that the 216 renews automatically while the 118 fails.
Log under messages (for the 118) says “likely firewall problem”.
I turn off the firewall and I do it manually and it renews!

Hmm! I’ll go over the rules again.
 
Last edited:
Yes, must be the firewall. when I disable it and renew manually, it works. I’m still scratching my head. Of course, to my understanding, we don’t know where will the next connection to renew comes from, otherwise, I’ll have that allowed in the firewall!

I might try to disable the firewall (hate to do that) 31 days before the next expiration and see what happens.

So am I right in assuming that the renewal request is initiated from the DS outwards?
Because the 216 doesn’t have 80 forwarded to it, yet it renews.

I remember that there was a lot of discussions around the ports required and the mechanism with no agreement. it was like a voodoo secret that no one knows.

—Edit—
At this moment, I’m caught wishing for a stateful firewall, like @Shadow :(
 
So am I right in assuming that the renewal request is initiated from the DS outwards?
It is initiated from the DS side but you need inbound port 80 open. Maybe your other DS has 443 inbound open and renewal is coming in that way?

On the whole topic of keeping it open or not. Personally I renew via dns validation not http but still I get a warning within the last 30 days that my cert is due to renew. So there is no real need for you to keep ports open until you get an email. After that just open it and renew it manually and then close it.
 
As I said above, in the log under /var/log messages it says:
Timeout during connect (likely firewall problem)"}

But I’m confused why is it allowed on the 216 although the firewall there is more restrictive. I was hoping that there is a place for more descriptive logs. Alas, not the case.

I’ll try to figure it out. If I do, I’ll update here. Thanks.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

QuickConnect is always exposed to Synology. Disabling it removes that exposure.
Replies
5
Views
1,689
Ah ha right I'm with you, now, in that case I'll not worry as it's a very small private forum and we're...
Replies
4
Views
3,173
I use google domains, but unsure of this is also considered google cloud. Yes there’s not much...
Replies
54
Views
11,792
  • Solved
If it is of interest, when I got caught by the 143 character limit, I used an app 'Path Length Checker' on...
Replies
7
Views
2,640
here I have summarized the keyholes in the DSM native settings, including how to avoid them: I tried to...
Replies
9
Views
5,354

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top