You could try creating a new SSL and see if that works. That is where I would start.

yes I did that already however tried it using the Veeam application itself which created a new SSL certificate and assoicated with the existing restore app registered in Azure for restore portal.  

however, I ran into the same error

Now I am going to try and create a SSL certificate using powershell and choose a algorithm diffrent than RSA256 like sha384ECDSA

no joy; may be I shall try and create a new app itself 

Only one I had is what Chris suggested...which obviously didn’t work for you @Seeker . Maybe try and share your post in the Forums to see what the Product Managers suggest, aside from what Support already did. Make sure to share your case ID so they can reference it. Curious to hear what they say...if anything different than Support.

Yes at this point a support ticket is probably the best route to take as they can assist better and you can post in the forums too once you have a case number.

I have posted it on the fouram as well and they advised to get in touch with support; which I did 2 weeks ago as a priority 2; 1 st week was spent on just revieing the logs and waiting for a repsonse; and I was told to reintsall the same cert; second week was spent at L2 support end to reproduce the issue and was eventually told to uninstall the Windows updates without any solid reasoning 

Then I suggsted installing a new cert with RSA algo and then later on a diffrent SSL cert with sha384ECDSA and both failed; wiered though the logs still reflect the same error although now we are using the new cert with sha384ECDSA

I had asked Veeam support to check if this request could be tested outside of Veeam or what exactly the api doing and what configuration of the OS can I check (Restore app uses MSAL)

and as Console restore are working and backup works fine as well; just do not want to risk uninstalling the windows updates and break the system totally; 

The only thing which I have not tried is registring a new app for restore portal with a new cert and rebooting the Office 365 server VM as that hosts REst api role as well; the reason for not rebooting is that we are running some backup copies although they all run on proxies (not VBO); I had asked this question before from Veeam support whether rebooting just the VBO will impact these copies which I understand wont as the copies run on the proxies however did not get a definative answer and infact they said to aviod rebooting Office365 when the copies are running.  

These were the updates installed also .NET Framework Version: 4.7.2 on the server; cant see anything wrong in app and event logs 

NEw app with new certificate created; services restarted; no joy ; after a lot of reseach I found that you can actually use powershell to get JWT token from Azure (I belive that’s what Veeam is doing when utilizing the restore portal: supoprt need to confirm) however it was throwing an error   “Invalid algorithm specified” which kind of similar error that we are getting with Veeam Restore portal logs 

Then I found this website : Solving client certificate "Invalid algorithm specified" issue in PowerShell | Tribework

when I created a new ceritificate with Powershell using switch -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider'

uploaded this certificate to a test App 

 the code to get the JWT token without any error : 

So the next step is to use this certificate with the restore app and see if this resolves the issue 

The article states 

PowerShell 5.1 depends on the .Net Framework 4.7 and uses ‘Microsoft Base Cryptographic Provider v1.0’, while PowerShell 7 depends on .Net Core and uses ‘Microsoft Enhanced RSA and AES Cryptographic Provider’.

So I will try and create a certificate with -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider' bound it to the APP and see if that works

Glad to hear you're able to make progress @Seeker . Let us know how the rest goes. 

Nice to hear some progress has been made with your issue @Seeker here is hoping it comes to a final solution.

I tried a diffrent provide to create the self signed certficate; although powershell cmdlet is now working fine; I can get the jwt bearer token however unfortuently the restore portal still returns the same error.  Chasing with support for their insights 

finally this issue got sorted; I was advised to uninstall .net or Windows updates; however; it turned out something changed and once I changed the front end certificate to be 
SHA256 rather than the previous certificate which was sha384ECDSA and more secure; it is now working although I am still checking with Veeam support if usage of RS256 is hardcoded somewhere as it was working before the latets version upgrade.  Again there are 2 certificates; one that talks to Azure app and uploaded against it; otherone was for the portal itself; which is signed by internal CA and had a higher algo; I had made multuple changes to back end however thought of just trying the change on the front end cert to see what happens and it worked; 

Great to hear you addressed it.  Let us know if this is a requirement.

The same certificate was working before so ideally yes as sha384ECDSA  is a mordern cert compared to SHA256