axility.net: Fix Certificate Issues on Development Machines

[Blog bot]

Источник: https://axility.net/en/fix-certifica...ment-machines/
==============

Since we moved to the new AX (#Dyn365FO) we use virtual machines to perform development tasks which are provided as images by Microsoft and either deployed to Azure or downloaded and run via Hyper-V on a local server. At least the latter suffer an issue at some point (age) that relates to expired certificates and that might be hard to overcome if you start from scratch. No worries – here’s some guidance that should help you to fix the machine.


Symptoms

On your development machine you cannot open the application in the browser anymore and face an error message like

There is a problem with the server Sorry, the server has encountered an error. It is either not available or it can't respond at this time. Please contact your system administrator.






If you check the event log using the Event Viewer you’ll find a warning message pointing to an ExpiredCertificateException there:

Process information: Process ID: 14516 Process name: w3wp.exe Account name: NT AUTHORITY\NETWORK SERVICE Exception information: Exception type: ExpiredCertificateException Exception message: Expired certificate for id 'C0E503DC8987D25B63897A7BE0B3E34BDCC89F41'. at Microsoft.Dynamics.AX.Configuration.CertificateHandler.LocalStoreCertificateHandler.GetCertificatesForId(String id) etc.








Not only you cannot open the application via browsing the URL (typically https://usnconeboxax1aos.cloud.onebox.dynamics.com/) anymore if this happened because of expired certificates – starting a form using the debugger and unit test execution are unusable at that stage, too! When it first appeared a couple of months ago almost all the development machines in our organization were affected. That was a stressful day at work… With a lot of trial and error and the help of the wonderful people on yammer (follow to see some more of the history of this) I was able to create a very specific guide to fix it which only worked for the machines of this particular age.

Solution

This week, it happened again. Some newer images were affected and this time the old solution didn’t work on these machines. Basically, the old approach was to take an existing and not expired certificate that is there already and replace all references of the expired ones to this one. But what to do if there is no suitable certificate? Exactly – create one.

Find Certificates

You can see the certificates that are relevant here using Manage computer certificates from Windows Start menu. Navigate to Certificates – Local Computer > Personal > Certificates.

In the column Expiration Date you can easily identify the ones that recently expired, in this case

• DeploymentsOnebox.DaxRunnerTokenUserCertificate.pfx
• DeploymentsOnebox.LcsClientCertificate.pfx
• DeploymentsOnebox.MRClientCertificate.pfx
• DeploymentsOnebox.SessionAuthenticationCertificate.pfx

As far as I know there is no way to extend the validity of such certificates. So, we need to use a different one.
Also, it is mandatory that some of the properties equal the ones of the certificates that are in place but expired. So, the best approach is to create clones! You can use PowerShell to do so – special thanks go to Brad Bateman for the hint to the according article on docs.microsoft.com.

Identify Thumbprint of Expired Certificate

Certificates get accessed by their thumbprint which is a 40-digit hexadecimal value. You can see it by double-clicking the certificate in the certificates viewer and open the Details tab.

Unfortunately, we need it to be upper case and without blanks so this is the right time to open the files that need to be modified later already. You can use any text editor or event VS, my preferred one for such operations is Notepad++. Make sure to run it as Administrator so you can save the files later without any issues. All three files we need are located in C:\AOSService\webroot:

• web.config
• wif.config
• wif.services.config

Use the first 4 digits or so to find the whole string in the web.config file. Make sure it’s the right one. Copy and note it in some other place (text file / OneNote / whatever you use for that). In my example here, this is 43082FE50B4D02562C89EA728B2363C598E84886 (and I searched for 4308).

Clone the Certificate

Use PowerShell (and Run as Administrator, of course) to execute the following command (and make sure to replace the thumbprint with the one you just identified):

Set-Location -Path "cert:\LocalMachine\My" $OldCert = (Get-ChildItem -Path 43082FE50B4D02562C89EA728B2363C598E84886) New-SelfSignedCertificate -CloneCert $OldCert -NotAfter (Get-Date).AddMonths(999)






999 is the number of months the certificate will be valid until. Should be fine for quite some time.
The execution of this creates some output – copy and note the thumbprint of the newly created certificate. In the certificate manager you can see the clone (you might have to Refresh after a right click on the folder on the left).


Update References

Use Notepad++ (slash the tool of your choice) to find/replace the old thumbprint by the new one in all three files mentioned and opened earlier. Backup the files before.


Repeat

Repeat this for all expired certificates. In the example there were four. I’d guess this differs from time to time. Don’t forget to save the files.

Reboot

It might be enough to start some services (IIS, Batch, SSIS, MR, SQL) on the machine but in such a case I prefer to simply reboot the whole thing which is faster than doing the restart one by one – if you do not have a suitable script for that around.

That’s it

AX should now be working again. Er, Dynamics 365 for Finance and Operations should be back in an operational state now