9
1
When you use the Remote Desktop Connection client to connect to a remote computer that does not have a valid SSL certificate, you are presented with a box similar to this:
I already know how to deal with this, to make the box not appear at every connection ("check Don't ask me again..."). I also know how to make the box reappear after "Don't ask me again" has been checked. (There are several posts to this effect here on superuser.) An option in this dialog allows you to review the server certificate.
My question is when using Remote Desktop Connection client to connect to a server that has a valid certificate issued by a trusted certification authority, how do I view the certificate? (Assume that I do not have access to the certificate store on the remote server.)
In the connection bar of Remote Desktop Connection version 6.3.9600 there appears a padlock, similar to what you might see in a web browser. However, clicking on the padlock only reveals
Again, how do I view the certificate used by Remote Desktop Connection when the certificate is valid?
EDIT: In my initial testing, I was using a client PC (non-domain) to connect to the server on the same subnet. The security (padlock) icon in MSTSC indicated authentication by kerberos. A subsequent test from a PC on a remote network indicated authentication by server certificate, and gave me the option to view the certificate.
So now I am wondering why the local connection authenticated by kerberos and the remote connection by certificate?
P.S. -- Credit for the error message image goes to Ian Boyd ( http://superuser.com/users/8169/ian-boyd )
– Jonathan J – 2015-02-13T20:02:08.060Is this a corporate network? e.g. a managed domain – dkanejs – 2015-02-13T20:04:10.783
1The server in question is in an Active Directory domain. The client PC is not joined to the domain, and has not imported the certificate. The server has supposedly been configured with an SSL certificate from a third-party certification authority, not the Windows CA in the domain. I need to verify which certificate is actually being used. – Jonathan J – 2015-02-13T20:08:07.170
The handshake may be recorded, you could check eventvwr on the client to see what certificate was used. – dkanejs – 2015-02-13T20:11:52.350
I found a workaround for what I needed to do... connect to the server by IP address rather than name. This forces the error message to appear, where I can click to view the certificate. However, it really doesn't answer the question of how to view the certificate when it's valid for the server named in the connection. – Jonathan J – 2015-02-13T20:30:17.853
Nice, was it available in eventvwr? – dkanejs – 2015-02-13T21:02:52.960
I did see some things in event viewer, but nothing that really helped. I assume that certs are only cached in memory for the duration of the session, not written to storage. – Jonathan J – 2015-02-13T21:12:53.897
Interesting, I thought it would at least list the thumbprint for auditing. Nice find though. – dkanejs – 2015-02-13T21:18:52.490
In my initial tests, I was using a non-domain client PC that was physically on the same subnet as the server. Clicking the padlock icon indicated that authentication was by kerberos. I just did another test from a client PC in a remote network, and the padlock icon indicated that authentication was by server certificate, and gave the option to view the certificate. So now the question: why was it authenticating by kerberos the first time and not by server certificate? – Jonathan J – 2015-02-13T21:19:17.023
If the client is on a remote network then the cert is used to sign the connection. Kerberos is local only so it would take precedence in that scenario. – dkanejs – 2015-02-13T21:21:50.737
I don't understand why Kerberos authentication was used if the client and server are not in the same domain. – Jonathan J – 2015-02-13T21:23:22.743
Same network/subnet though right? I've read through the wiki and it explains it well, I'd check it out, interesting fallback methods. (Too much for a comment). – dkanejs – 2015-02-13T21:26:27.627
@dkanejs, do you happen to remember what wiki you were referring to here and where we can find it? I'm facing the same problem as the OP - the Remote Desktop client is telling me "Kerberos" under circumstances where that seems unlikely. – Harry Johnston – 2019-09-16T00:30:14.210