In my case, the previous certificate had expired, and the server generated a new one. I projected that this was the case based on the timing of the certificate change, compared to when the original certificate was created. I then verified that this was the case by accepting the new cert, logging in, and inspecting the certificate stored on the server, as well as server logs indicating these changes had taken place. The fingerprints matched.
As far as I can see, it would not be possible to verify this theory without accepting the new cert and logging in, unless you had another vector of access to the server, like a remote console (ssh, etc.) an ftp server, or perhaps a reverse shell.
If security is something you value in your connections to your RDP server, you should set the date of expiration on your certs manually, and/or put a reminder in your calendar.
If this had been a man-in-the-middle attack, and I had accepted the cert and logged in, the attacker would then have not only my login credentials, but also have full capturing ability for my session, and any future sessions in which I connect to the intercept server.
Of course, there is the slight chance that I have connected to an intercept server, and the attacker managed to either update the cert on my server between the time I logged-in, and the time I retrieved the server cert. Or perhaps the intercept server edited the graphic data being sent to my client RDP viewer, to match the fingerprint of the intercept server. Though I perceive these to be highly unlikely.
