Rory has the right answer here, but I wanted to add more. I tried to squeeze it into a comment but it's too big for that, so I'm posting an answer.
Checking the issuer is the easiest way to identify a MITM, although as noted also by Rory the MITM might not be an evil man in the middle, security software can be doing this.
About checking the issuer, I'd use Firefox to get the cert information. If Firefox is not accepting the issuer CA, and the CA is installed on the local machine, I'd say its MITM and delete the cert from the OS cert store. Firefox embeds its own store of trusted CAs and does not trust the OS stores. However, it's sadly trivial to transparently modify Firefox's trusted CA store too, so it's not a guaranteed way to check.
On Windows with things like WFP a MITM can be set up without modifying any of the settings on the OS, making it very difficult for a user to clearly identify the source software behind the diversion. WinDivert is an example of such a library, it makes it trivial to set up something like a MITM without changing any observable configuration values. However, hooking into the WFP requires creating a signed driver.
So, to catch these attacks as well, you can check installed/running services and drivers from a console with administrator rights with two queries:
To get installed/running services:
To get installed/running drivers:
Note that this will only help clearly decide if something is intercepting HTTPS traffic locally. Identifying and cleaning up whatever is responsible is a different matter altogether.