Can’t access my NAS via browser

[WST16]

I have a problem accessing my DS118. Something to do with the certificate maybe.
Safari and Firefox give the usual warning, however, no option to choose to visit the site.

Safari on the Mac says the certificate is revoked! This is the first time I see such a message!

The certificate was showing in orange color (meaning it’s still valid for a month or less).
I usually renew manually. I turn off the firewall, run the renew task, it renews for another 3 months, turn on the firewall. Done. I intended to do that within the next few days.

I can SSH. I did a shut down (shutdown -h now) and waited for a few minutes, pressed the power button and after a while it comes up. Still, the same problem!
But I can SSH to it!

HTTP is redirected to HTTPS so I can’t use it.

Any suggestions?

 

[WST16]

I think as a starting point, I should disable redirection of http to https and see if I can gain access.

For nginx, I think it’s under
/usr/syno/etc/synoservice.d/httpd-user.cfg

If anyone knows more about how to go about doing this, please share.

Thanks.

 

[WST16]

Tried a few things to no avail. Ended up using the clip and (reluctantly) did a rest.

I restored everything and renewed the certificated. It's green now and valid until February 14. However. Browsers and TLS Inspector still shows it as revoked!

 

[Rusty]

Sorry to hear that you are having trouble with this. Could it be that your domain provider has something to do with it? I don't think LE would revoke any cert on their own unless there was a reason for it. Maybe it would be an idea to contact your domain provider and ask them a bit?

 

[WST16]

Thanks @Rusty.

I checked the DNS propagation and it's fine. I'll try to open a support ticket but I'm sure they'll come back and say it's your certificate (although that shouldn't have anything to do with it). Not even sure what to ask for!

But it's highly likely that it has something to do with them
I've had a few problems with them before! Maybe I should consider moving the domain somewhere else.

 

[Rusty]

I'm sure the DNS propagation is fine, otherwise, you wouldn't even get to your services, but maybe they are flagged from LE side or are flagging LE certs as "unwanted"... Who knows.

 

[WST16]

Thanks.
It could be them. Just raised a ticket. Bad timing for this to happen. I'm flying on Saturday! Must fix this. Nothing is working now. No email and no website access.

 

[WST16]

It’s @SynoMan fault :p
He’s the one who asked us to post pictures of our NASes. I posted and said that the 118 is very impressive. I jinx it

Although to be fair it has nothing to do with the DS, but I’m going to blame someone

 

[SynoMan]

Ok, I hope you'll fix it asap.

 

[WST16]

It seems this has something to do with DSM 6.2.2-24922 Update 3. I found this.
I tried the suggested add and replace, but now it says:

So in my case it might be more than one thing causing the problem.
But take note if you’re still on update 3, this might happen to you. They’re saying it’s fixed in update 4!

So my problem is still not resolved yet.

 

[Rusty]

Haven’t noticed it on up3 or 4

 

[WST16]

Yes. My 216 updated the LE certificate by itself as usual with no problems (and it’s on update-3, same as the 118). I’m guessing maybe because the 118 was “not allowed” to auto update the certificate (firewall rules), this happened because of the highlighted bug (above) with update-3.

Another strange thing is that when I tried to delete the LE certificate, the option was dimmed.
I updated to update-4 and moved the services (configure button) to the Synology certificate (I still have it), tried again to delete the LE certificate, the delete option is still dimmed.

I moved the services back to the LE certificate. Out of curiosity, I tested with TLS Inspector and voila, it says it’s a “trusted chain”! Browsers can access with no problems and the mail service is back to normal!

So the problem is solved. Don’t ask me how!
Did it take a while after the update (and moving the services from one certificate to another and back) to sort things out! Not sure. I have no idea what went on and I hate it when things don’t make any sense!

Now, I’d like to recreate the certificate to add some subject alternative names and it still says: failed to connect... (the message in the shot above)! That’s one thing that’s remaining.
Maybe I shouldn’t mess up with it now since everything’s working and leave it until I’m back.

I have a ticket with Synology.

 

[WST16]

I'm sure the DNS propagation is fine, otherwise, you wouldn't even get to your services, but maybe they are flagged from LE side or are flagging LE certs as "unwanted"... Who knows.

BTW, I was on LAN using the IP address to access the DS. So it doesn’t matter even if the DNS propagation was faulty– it wasn’t. And that’s what was confusing because I couldn’t access anything validated via the certificate because it’s “revoked “!

And as expected, my domain name and DDNS service provider (changeip.com), replied saying: “check with your web service provider, we only manage the domain“ and closed the ticket. How rude

I‘ve used their support a few times and they’re not exactly helpful. Avoid.

Anyway, things are working now. I’ll see what will Synology say.

 

[jeyare]

this story is better than from Stephen King
good luck
maybe (if possible) it’s a time to use fixed IP and your own domain

 

[fredbert]

@WST16 have you tried going into Keychain Access and deleting the saved certificates assigned to the NAS LAN IP? I've seen that Safari and Firefox decide not to offer the option to add an exception and think I played with removing old cruft from this app. Might be worth a shot.

 

[WST16]

@WST16 have you tried going into Keychain Access and deleting the saved certificates assigned to the NAS LAN IP? I've seen that Safari and Firefox decide not to offer the option to add an exception and think I played with removing old cruft from this app. Might be worth a shot.

No I didn’t. My focus was to make the services reachable for my “external“ colleagues. I used TLS inspector and it was saying the certificate is revoked.
But on a second thought that might‘ve been useful (if it works) to gain access when it was not allowing me because http was redirected by DSM (as I configured it) to https. I doubt it though. But a good suggestion to keep in mind. Thanks

 

[WST16]

this story is better than from Stephen King

It’s a waste of time. I just kept documenting it here in case someone faces the same. Unfortunately, it makes no sense, and the result is not a proven fix because I don’t know what’s the problem to begin with and how it was fixed (or if it’s truly fixed).

We might as well delete this thread

maybe (if possible) it’s a time to use fixed IP and your own domain

What do you mean by “own domain”?
I’m using my own domain, unless there is another thing I don’t know about!

 

[WST16]

Below is Synology’s response to my raised ticket.
At last some sense amid all the chaos!
Note that (as they said) this happens if the certificate fails to renew, which is exactly my case.


Any idea why it was showing as revoked in the first place?

-> Yes, that was a known issue with DSM 6.2.2 Update 3. It was actually from Let's Encrypt official document design that if the renewal of the certificate failed for whatever reason, then revoke the certificate automatically. In DSM 6.2.2 Update 4, we changed the renewal process, so instead of revoking the failed renewed certificate right the way, it will let the users continue to use it until it expired or successfully updated.

 

[Telos]

if the renewal of the certificate failed for whatever reason

But no reason given for all of the failed renewals?

 

[WST16]

The certificate on my 118 always fails to renew. Something to do with the firewall according to the log in messages:
Timeout during connect (likely firewall problem)

I’m not sure what (didn’t spend time investigating). So any suggestions are welcome
A logical test would be to switch off the firewall and see, but I can’t afford doing that, so I’m letting it drag.
What’s puzzling me is that the 216 has more restrictive firewall rules, yet renews by itself successfully every time.
So the need to renew the 118 certificate manually is not new to me.

However, what’s new, is that this time when it tried to renew and failed, it didn’t simply continue as before, it decided to do a “Seppuku” and take its own life (revoking) according to the “new” way of handling the certificate in update-3, as was mentioned.

With update 4, Synology claim’s that they’ve put back everything as it was before the introduction of the “Seppuku” stunt