Restore portal not functioning after latest patch and windows update

[rtheseeker]

Ran into this issue where in the restore portal seem to not go past the initial login screen(tried on diffrent systems and browsers). already have a case with Veeam support however could not understand the steps
Rest api service is on the same server as VBO
I can see the Veeam.Archiver.Rest Logs and it has following entry which I could not see in historical logs
"
[29.02.2024 14:18:22.510] 72 (12244) Error: IDX10634: Unable to create the SignatureProvider.
Algorithm: 'RS256', SecurityKey: '[PII of type 'Microsoft.IdentityModel.Tokens.X509SecurityKey' is hidden.
"
I had also patched the server yesterday as well (Windows update)
The restore portal appears okay and I can authenticate to the Azure portal using my credentials however after that it does not proceed

the application certificate is installed on the VBO server(is has Rest services running as well)
Certificate with thumbprint BBXXXXXXXXXXXX exists in the following locations:
Cert:\LocalMachine\My
Cert:\LocalMachine\Root

and it is the same cerifitcate showing fine on the Azure portal >App registration> Restore App

looking online it appears that it has to do something with the KeySize
Case #07156402

also, I logged this as a priority 2 however got an email and no response again so far although I had replied to that email last night
reponse from support
"Use the REST API configuration for certificate and generate a new Veeam certificate for it.//how is this done; why are we doing this does the existing certificate has some issues; this will prolong the resolution as I will have to ask someone from the Cloud team to add the certificate to the app again ??
The certificate is not trusted/hidden apparently on the REST API machine.
Use the Run command and type MMC then enter to open the console.
Add snap-in the certificate section for computer account and local account.
Ensure that the certificate is added on both sides in the folder for Trusted Root Certification Authorities.
Then restart the Veeam server when there are no backups running and the problem should be solved.
"

[Mike Resseler]

Hey,

Unfortunately it is impossible for us to solve this without the full logs and research that needs to be done by our support team. If you feel they are not replying please use the escalation on the support portal.

I hope nothing has been broken by the windows update, but seeing the error I think there is something wrong with the app registration, but at this point I am guessing

[rtheseeker]

okay I have been advised to uninstall the windows updates and I am bit skeptic to do that.
The reason is the restore console is funtional and so is the backup which as I understand is using app/certificates as well
I have tried a new self signed certificate; added that to Trusted Root CA on the local computer as well
Shall I may be try creating a new app
Also, does restarting Rest API service on the server is sufficent or do I need to reboot the server; at the moment we have multiple backup copy jobs running on diffrent proxies; although I think rebooting VBO wont impact those as proxies are difffrent servers

Error: IDX10634: Unable to create the SignatureProvider.
Algorithm: 'RS256', SecurityKey: is not supported. The list of supported algorithms is available here: https://aka.ms/IdentityModel/supported-algorithms
I have checked RS256 is supported and also as other funtions of VBO using the self signed certificate are working I suspect that to be the issue

14.03.2024 09:30:11.727] 55 (19664) Authorization started (grant type: OperatorAccessTokenResponse)
[14.03.2024 09:30:11.791] 57 (10412) Action started: GET https://Restore Portal:4443/v7/Organizations/xxx/Users?dataSource=PreferLocal&limit=500&offset=69000&setId=a55d662c-4b73-41e4-9432-6d9895cfc2b1
[14.03.2024 09:30:11.798] 57 (10412) Action completed successfully: GET https://Restore Portal:4443/v7/Organizations/xxx/Users?dataSource=PreferLocal&limit=500&offset=69000&setId=a55d662c-4b73-41e4-9432-6d9895cfc2b1
[14.03.2024 09:30:11.912] 55 (19664) Connecting to Veeam Backup for Microsoft 365 server at 127.0.0.1:9194...
[14.03.2024 09:30:12.113] 31 (10124) Action started: GET https://Restore Portal:4443/v7/Organizations/xxx
[14.03.2024 09:30:12.122] 31 (10124) Action completed successfully: https://Restore Portal:4443/v7/Organizations/xxx
[14.03.2024 09:30:12.257] 55 (19664) Successfully connected
[14.03.2024 09:30:12.260] 55 (19664) Authorization succeeded
[14.03.2024 09:30:12.261] 55 (19664) Error: IDX10634: Unable to create the SignatureProvider.
Algorithm: 'RS256', SecurityKey: is not supported. The list of supported algorithms is available here: https://aka.ms/IdentityModel/supported-algorithms
[14.03.2024 09:30:12.261] 55 (19664) Type: System.NotSupportedException
[14.03.2024 09:30:12.261] 55 (19664) Stack:

[rtheseeker]

also I did raise this issue 2 weeks ago as a priority 2(29th Feb); 1 st week was spent on just reviewing 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 self-signed 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 does it not use the same mechanism in terms of how certificates are used during the console restore; 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

[rtheseeker]

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 in the update