That was what I was getting at when I suggested you check the fingerprint of the key and the certificate. OpenSSL provides a commandline tool for generating the fingerprint of both the certificate and the key, and they should match. (This is what your checker will have done.)
As to how this comes about, quite simply the key and the certificate have been muddled. Either the Key you now have is not the key which against which the original CSR was created, or the certificate you have was not generated from the CSR you provided. My previous role required managing SSL certificates for multiple hosts and services, so there were standard processes for generating keys, CSRs and resultant certificates externally. When certificates were altered for Splunk I replaced them and altered the configuration to match manually. I never used Splunk to create the initial request, so I'm not sure where the procedure is that you followed, but an error like this essentially derives from human error.
Although it is configuration dependent (i.e. the local administrator can alter the location in web.conf), the default location for your web certificates is:
~splunk/etc/auth/splunkweb/privkey.pem
~splunk/etc/auth/splunkweb/cert.pem
I would search the whole of ~splunk/etc/ for .pem files, and check timestamps. You might be able to locate a match that way, if you can remember the date of generating the original request. Otherwise you will just have to generate a new key (or use an existing key), create a new CSR from it, and request a new certificate to match the new key. There is no feasible way to work backward if you cannot find the matching key for your certificate. (If there was SSL would not be secure...)
For a crash course in openssl certificate handling tools you could do worse than look at this summary
... View more