Installing SRM 8.2 appliance error: A specified parameter was not correct: connection.thumbprint

If, like me, you use a Chromium based browser and you are having issues registering your second SRM server to your second vCenter server, you may encounter the above error message, as shown in the screen shot below during the registration process.

I spent quite some time digging around in various log files on the SRM appliance as well as the vCenter Appliance and what I saw was that although the initial SSL thumbprint was coming from the desired vCenter Appliance, it was also receiving a thumbprint from the first appliance. How peculiar.

In the /var/log/vmware/srm/drconfig.log file on the SRM appliance you may see errors similar to below:

2019-07-18T16:57:54.009Z verbose drconfig[01472] [SRM@6876 sub=ProbeSsl.Url.DrConfigSslCertificateManager] Established TCP connection to ‘vcenter2.chris.local:443
2019-07-18T16:57:54.013Z warning drconfig[01472] [SRM@6876 sub=ProbeSsl.Url.DrConfigSslCertificateManager] SSL client handshake to ‘vcenter2.chris.local:443’ failed.
–> N7Vmacore3Ssl18SSLVerifyExceptionE SSL Exception: Verification parameters:
–> PeerThumbprint: 93:98:0A:06:54:BA:58:FD:77:E2:B1:99:B0:84:11:3C:6A:E6:35:5E
–> ExpectedThumbprint:
–> ExpectedPeerName: vcenter2.chris.local
–> The remote host certificate has these problems:
–>
–> * unable to get local issuer certificate
2019-07-18T16:57:55.414Z verbose drconfig[01677] [SRM@6876 sub=ProbeSsl.Url.Default] Established TCP connection to ‘vcenter1.chris.local:443’
2019-07-18T16:57:55.419Z warning drconfig[01677] [SRM@6876 sub=ProbeSsl.Url.Default] SSL client handshake to ‘vcenter1.chris.local:443‘ failed.
–> N7Vmacore3Ssl18SSLVerifyExceptionE SSL Exception: Verification parameters:
–> PeerThumbprint: 87:C0:18:74:EA:C9:4E:C1:02:5F:B6:84:B1:DB:01:43:7F:E4:F9:D2
–> ExpectedThumbprint:
–> ExpectedPeerName: vcenter1.chris.local
–> The remote host certificate has these problems:
–>
–> * unable to get local issuer certificate

Although I was attempting to register the appliance to vcenter2.chris.local, I couldn’t understand why it ended up receiving a certificate from vcenter1.chris.local (which was previously configured). In theory, it shouldn’t be possible.

Annoyingly, I spent more time than I should have on this, posting on reddit and the VMTN in search for an answer. Quite often in IT, the solution to problems often comes down to something as simple as switching your browser or enabling incognito mode. In my case I used Firefox (or it may have been Edge!) and it resolved the problem.

I’m not sure what it stemmed from, I can only assume that some auto complete information in the browser for the first SRM appliance was being passed to the second SRM VM when configuring it.

I hope this helps someone out as I did Google this and I couldn’t find any help at the time!