HTTP 500 errors running Dynamics 365 for Finance and Operations in locally hosted onebox / development VM

If you are hosting your own onebox / development VM (instead of hosting it in LCS), you might suddenly discover that you get HTTP 500 errors trying to run the local instance of D365. As of this writing, it should have just started cropping up for 7.3 VMs.

This is because the certificates used in these VMs expire. Why did Microsoft include certificates that expire so quickly?… I guess they were overly optimistic about our ability to move on to later versions. But it was a problem in previous VMs, and continues to be.

Fortunately, fixing this problem is documented. (https://blogs.msdn.microsoft.com/lcs/2018/04/24/rotate-the-expired-or-nearly-expired-certificates-on-your-downloadable-vhd/) Unfortunately, that document has some minor errors, and leaves out some useful details. (It’s also hard to find sometimes.) So, to save you some of the trouble we’ve had, here are my slightly improved steps for fixing the problem. (EDIT/NOTE: Check the comments on this post for a solution that should do all of this in a single Powershell script; it’s almost definitely easier than my original steps posted here.)

(1) Run “Windows Powershell” AS AN ADMINISTRATOR from the Start menu, and paste in this command:

Get-ChildItem-path Cert:\LocalMachine\My | Where {$_.NotAfter -lt $(get-date).AddMonths(2)}| Sort NotAfter | Format-Table Subject, Thumbprint, NotAfter

(2) You’ll get a list of several certificates. Record them in the first column below, leaving the second column blank until the next step. (Fortunately, the Powershell window allows you to select text in a box shape.) You might want to create your own copy of this in Notepad in your VM.

Old cert thumbprint (listed by step 1)     New cert thumbprint (generated in step 3)
-----------------------------------------  -----------------------------------------
2C669BD45BB8A0305F4F962A175FF4FD6B4CAD7C   266DB189E56BE7E036019D34994480071C47B92B
217695F9CE7033413ECB5F059FC4C4B0F439C102   EF84A2876504B1AE2AE86408733FBA8002BA0CF9
4C82C05E452D08A2BE1CC4F92DA24CF98E493F1D   193539F1E914DD9888D29AFD70E83F008FE7709F

(Note that the above thumbprints are examples. Don’t use them!)

(3) One at a time, generate a new certificate that is a copy of the expired certificate, but dated for far in the future. (999 months, to be precise.) Use this script (but replace the thumbprint obviously) for each old cert you found above:

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

Record the thumbprint generated for the new certificate next to the old one. You’ll need both shortly.

(4) Launch notepad AS AN ADMINISTRATOR three times. Open the C:\AOSSERVICE\WEBROOT *.config files (web.config, wif.config,wif.services.config). Search/replace each old cert thumbprint with the new cert thumbprint.

You won’t find every thumbprint in every file. Be careful; accidentally including a trailing space, or cutting off a single character, can lead to this not working and being difficult to debug later. Sorry, this step is pretty tedious!

(5) Restart IIS by running the iisreset command in your Powershell window. If it works, you’re done, and should never need to repeat this for this virtual machine. (Unless you are still using it 999 months from now, which I’d hope you are not!)