Do You Used Synology Active Backup For Business ? This may be important if you do.

[David M]

I checked to see how my Synology Active Backup For Business (ABB) was working the other day and found out that it wasn't. I have two Windows PC's that both quit backing up on March 12. The short version of the longer story is that I went into the Windows ABB app and found that there was a certificate trust issue. Just click on Trust the certificate ( twice in my case.) This should fix your problem if you have one. I suspect that there was a Synology update that made this quit working.

 

[fredbert]

This has been discussed before. Basically the issue is that the ABB client loses trust if the certificate is changed or renewed and it then cannot validate the new certificate (e.g. if it is self-signed).

Have a look at this thread, and there are some others that touch on this too if you scroll through this forum.

Beware: ABB will silently stop working if SSL certificate is changed

I am positing a warning for others: If the SSL certificate on your NAS is changed, all of your Active Backup for Business tasks will stop working. But it will not show up as a failure! The tasks will still show as "successful", just as of some date in the past! This is a huge issue, as you...

www.synoforum.com

 

[Rusty]

In fact this is a known “issue”

 

[ed.j]

Well that is pretty rubbish, thanks for the heads up.

 

[fredbert]

Well that is pretty rubbish, thanks for the heads up.

The fact that it does it silently is really rubbish.

But once you have a signed certificate that covers the FQDN or a 'long-file' self-signed/other certificate then this silent fail won't happen. It's only when the certificate changes and the ABB client needs you to actively re-approve it that this happens.

 

[David M]

Part of the problem that I ( and others, I'm sure ) have is that I have to google FQDN to understand what that means and the whole self signed certificate is something that is a bit above my technical pay grade. It just shouldn't be this way. Perhaps "Business" in the app's name should have been my first clue. I'll keep using it for now but have other backup plans running in other ways. It's has still been a great learning experience though and I appreciate the comments from the more knowledgeable posts above.

 

[ed.j]

The fact that it does it silently is really rubbish.

But once you have a signed certificate that covers the FQDN or a 'long-file' self-signed/other certificate then this silent fail won't happen. It's only when the certificate changes and the ABB client needs you to actively re-approve it that this happens.

I think I should be ok then. There are three certificates on my nas:
1. For my website (my.website.com or whatever) from LE - I think this is the FQDN cert?
2. quickconnect cert
3. Synology cert

In Settings/Certificates, ABB is set to use certificate 1 - so as per your post I think I shouldn't have this problem?
Or will I just have the problem as soon as I renew the certificate.... or "renewing" specifically isn't getting a "new" cert so it doesn't matter?

From memory the first time I set up ABB it asked me to approve the cert because the local IP address obviously isn't my.website.com.

 

[fredbert]

Certificate 1 will work fine if you assign a LE cert that covers the FQDN that you use in the ABB client: meaning the FQDN is the certificate's domain name [common name] or you added it to the SAN list [DNS names].

It's all about ensuring the server name you use in the clients when connecting to ABB server is included in the list of names of the certificate you assign to ABB. That, and that the certificate is signed by an entity that the client can validate (so not a self-signed cert.).

When it comes to the time to change the certificate, the LE certificates you create will auto-renew and these are fine (no silent fail, the backups will continue). Only if the client cannot itself validate the signer will the connection fail, and then you will have to go to each client to Edit Connection and re-confirm you trust it.

The good news, I found, was that if you change the certificate at the NAS end and this can now be validated by the client (known signer, and covers the server name) then the clients will start working again... without you having to go to each one!

Note: the ABB client server name doesn't have to be the same as the ABB portal because it is using a dedicated TCP port. That means you should ensure the right certificates are used for each part of the ABB service. But since the ABB client assumes the server name can be used to access both the backup service and portal it makes sense to use the same one, and advise users to do likewise.

Mostly, non-Web services don't care how you route to their network ports, but Web services can discern this (e.g. through reverse proxy rules). This is why you can use whatever server name or IP address to access TCP NNNN service and it will work until there is added encryption then the client may complain if the certificate doesn't match the name it used to route to the server. It's the client that cares, not the server.


Synology Drive is another one that has desktop connections on a dedicated TCP port and mobile/web connection to Web portal port. This too needs to have the right certificates assigned to each one. Again it's best to use the same server name for all clients and Web portal, then the same certificate can be assigned.

 

[fredbert]

I have to google FQDN to understand what that means

Getting old and just trying to reduce the amount of typing I do

 

[7Natives]

I have encountered the same issues. I admit, I did find it's not "silent" as other posters have said, or even hidden providing you know where to look to see it's erroring out, but it's not "glaringly obvious" either. And if the user is using Let's Encrypt free certificates as many of us are, it is now happening every 90-days or so because auto-renewing changes the code slightly, then every client has to manually re-authorize the whole thing. If you only have one client it's no big deal, but if you have several, and the users are all over the map in their capabilities, it quickly goes from inconvenience to major issue to nightmare.

Certificate 1 will work fine if you assign a LE cert that covers the FQDN that you use in the ABB client: meaning the FQDN is the certificate's domain name [common name] or you added it to the SAN list [DNS names].

It's all about ensuring the server name you use in the clients when connecting to ABB server is included in the list of names of the certificate you assign to ABB. That, and that the certificate is signed by an entity that the client can validate (so not a self-signed cert.).

Please explain how, in DSM 7.x, we can do this with a LAN connection wherein the client is connecting not to a FQDN (Fully Qualified Domain Name for those who like me and @David M had to Google it) but to an IP on the local LAN, e.g., 10.1.10.11.

This wasn't an issue in DSM 6.x, but with DSM 7.x it has become a real problem that even Synology Tech Support engineers are struggling with.

The good news, I found, was that if you change the certificate at the NAS end and this can now be validated by the client (known signer, and covers the server name) then the clients will start working again... without you having to go to each one!

Note: the ABB client server name doesn't have to be the same as the ABB portal because it is using a dedicated TCP port. That means you should ensure the right certificates are used for each part of the ABB service. But since the ABB client assumes the server name can be used to access both the backup service and portal it makes sense to use the same one, and advise users to do likewise.

Mostly, non-Web services don't care how you route to their network ports, but Web services can discern this (e.g. through reverse proxy rules). This is why you can use whatever server name or IP address to access TCP NNNN service and it will work until there is added encryption then the client may complain if the certificate doesn't match the name it used to route to the server. It's the client that cares, not the server.

Synology Drive is another one that has desktop connections on a dedicated TCP port and mobile/web connection to Web portal port. This too needs to have the right certificates assigned to each one. Again it's best to use the same server name for all clients and Web portal, then the same certificate can be assigned.

Well that would certainly be good news to me! I've got laptops and desktops and remotes all doing this and it's quickly approaching nightmare status. Can you expound each of these, perhaps with examples, for the dense(r) amongst us, like me?

7

 

[fredbert]

Please explain how, in DSM 7.x, we can do this with a LAN connection wherein the client is connecting not to a FQDN (Fully Qualified Domain Name for those who like me and @David M had to Google it) but to an IP on the local LAN, e.g., 10.1.10.11.

This wasn't an issue in DSM 6.x, but with DSM 7.x it has become a real problem that even Synology Tech Support engineers are struggling with.

That never worked for me in DSM 6. I run a local DNS service that resolves my personal domain to LAN IPs, everything else the DNS server forwards to an Internet DNS server. This way I can use the same server names and URLs at home and when away.


As for LE certificates renewing, I've not experienced the ABB client stopping. If the certificate is valid for the server name you are using, and it has been signed by a known entity then the client should start backing up without your intervention.

 

[7Natives]

That never worked for me in DSM 6. I run a local DNS service that resolves my personal domain to LAN IPs, everything else the DNS server forwards to an Internet DNS server. This way I can use the same server names and URLs at home and when away.

I'm not familiar with the "local DNS service". Is this something you setup on the Synology? How do you get the endpoints to use multiple DNS servers? And what about the router (mine uses Google, i.e., 8.8.8.8 primary and 8.8.4.4 backup). I'm struggling with getting LAN endpoints to stay connected due to the LE cert updates. When the endpoints are off-site, they come in using DDNS or QuickConnect and work fine, but every endpoint on the LAN, permanently or while visiting, fails.

7

 

[fredbert]

I use DSM’s DNS Server package. Create a master zone for my domain and then set forwarding to OpenDNS. In my DHCP settings on the router I direct clients to use the NAS for DNS server.

 

[7Natives]

Oh, OK, I think I get what you're doing now. So essentially all of your local traffic — including the router — taps the server for DNS data, then hits a (external?) fallback if not found, yes? Do you have a large number of clients on the network? How do you handle the day-in day-out endless DNS updating that external dedicated DNS servers do? How do you like OpenDNS vs. Synology's freebie DSCloud vs. DynDNS?

 

[fredbert]

That's what I'm doing

My domain's master zone is fairly static [now]: I reserve IP's in DHCP (on my router) for my main devices and then create an A record in DNS Server for the same IP. I then create a lot of CNAME records pointing to the A record when I want to have many names to the same device.

Using DNS Server's Resolution page you set the external (or next hop) DNS server IP addresses that you will use if the request cannot be resolved by DNS Server. I've selected the 'Forward Only' policy. It's also possible to configure from which IP ranges the DNS Server with accept requests: set this to LAN ranges.

I've used OpenDNS for years. Never used DSCloud and stopped using DynDNS when their DDNS prices shot up some years ago.

 

[7Natives]

Thanks for clarifying all of that!

 

[ed.j]

Certificate 1 will work fine if you assign a LE cert that covers the FQDN that you use in the ABB client: meaning the FQDN is the certificate's domain name [common name] or you added it to the SAN list [DNS names].

It's all about ensuring the server name you use in the clients when connecting to ABB server is included in the list of names of the certificate you assign to ABB. That, and that the certificate is signed by an entity that the client can validate (so not a self-signed cert.).

When it comes to the time to change the certificate, the LE certificates you create will auto-renew and these are fine (no silent fail, the backups will continue). Only if the client cannot itself validate the signer will the connection fail, and then you will have to go to each client to Edit Connection and re-confirm you trust it.

The good news, I found, was that if you change the certificate at the NAS end and this can now be validated by the client (known signer, and covers the server name) then the clients will start working again... without you having to go to each one!

Note: the ABB client server name doesn't have to be the same as the ABB portal because it is using a dedicated TCP port. That means you should ensure the right certificates are used for each part of the ABB service. But since the ABB client assumes the server name can be used to access both the backup service and portal it makes sense to use the same one, and advise users to do likewise.

Mostly, non-Web services don't care how you route to their network ports, but Web services can discern this (e.g. through reverse proxy rules). This is why you can use whatever server name or IP address to access TCP NNNN service and it will work until there is added encryption then the client may complain if the certificate doesn't match the name it used to route to the server. It's the client that cares, not the server.


Synology Drive is another one that has desktop connections on a dedicated TCP port and mobile/web connection to Web portal port. This too needs to have the right certificates assigned to each one. Again it's best to use the same server name for all clients and Web portal, then the same certificate can be assigned.

Thanks very much. Have been on bit of a knowledge rollercoaster over here but I think I'm with you. Sort of. Will see what happens when the certificate renews!!

 

[7Natives]

[mounting soapbox]
The whole problem with this is that self-signed certificates do exist for very good reasons, such as R&D, testing, local resource, etc. Eliminating self-signed certificates in DSM 7 by Synology and forcing users to engage this morass is utterly ridiculous and Synology never should have done this. Now we're all stuck (many dirty words).

I'm grateful for @fredbert 's work-around, but it should not be necessary, and even the work-around which @fredbert has so graciously shared explained in some detail in this thread carries the caveat: "Only if the client cannot itself validate the signer will the connection fail, and then you will have to go to each client to Edit Connection and re-confirm you trust it." That very item is the 'gotcha'.
[dismounting]

I wonder if there is a way to allow the client endpoints to self-validate in the same way the endpoint user is currently required to do manually every time the LE certificate renews? It would need to be a way that is very restricted.

7

 

[fredbert]

I’ve not seen how to enable the client to bypass signing validation. The other mobile apps have that option (not that I’ve checked recently) usually buried behind a cog icon on the login screen.

I’m guessing the assumption is the main users of ABB are businesses and they will be using signed certificates and FQDN as server name.

 

[jeyare]

I’m guessing the assumption is the main users of ABB are businesses and they will be using signed certificates and FQDN as server name.

I doubt it.
Synology main focus is for home users with 4bay NASes (still and many years)
Then less part of the NAS owners (minority) are ABB business driven usage or knowledge driven people. What makes the question unclear: how is the ABB positioning defined?