Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I am using Microsoft's RDC client on Mac OS X, to connect to a Windows server. I am connecting to a RDC server that uses a self-signed certificate to identify itself. As a consequence, when I connect, my RDC client gives me a warning dialog like this:

The certificate is not from a trusted certification authority (CA)

I can click "Connect" to continue, but then I have no security against man-in-the-middle attack, because "Connect" instructs my client to ignore the server cert. I want to continue to connect, but in a way that is secure.

Another option is to go to the Microsoft RDC client's preferences pane:

RDC client preferences pane: Security

and switch to "Always connect, even if authentication fails". This way, I'm never shown the warning again: it's as if I automatically clicked "Connect" every time. However, again, this is not secure: it skips authenticating the server, and thus is vulnerable to man-in-the-middle attacks.

I want to be secure. Therefore, neither of the two approaches above is satisfactory.

Conceptually, the obvious path forward is to somehow gain access to the server's self-signed certificate, and then ask the RDC client to treat it as trusted and never warn me about that certificate again. This would be secure (like SSH). However, I can't figure out how to get my RDC client to do that.

How do I arrange for this server's certificate to be treated as trusted (despite the fact that it is self-signed), and have the system never warn me about connections that use that particular certificate, but still provide security (e.g., warn me if the certificate changes)?

share|improve this question
    
Have you tried adding the self-signed certificate to Applications>Utilities>Keychain Access? In this article about Chrome robpeck.com/2010/10/… the certificate is added to the System keychain, this article about Microsoft Entourage kb.kerio.com/article/… says to add it to X509Anchors keychain. Could you try it and report back? –  jaume Nov 29 '12 at 9:34
    
I've tried adding it to the System keychain, the login keychain, and the Microsoft_Intermediate_Certificates keychain. In all cases I marked it as "Always Trust". None of them worked: I continue to get the warning message. I could not find any other keychains to import it into. Thanks for the idea, though, @jaume! –  D.W. Dec 6 '12 at 22:23
    
P.S. I was unable to follow the instructions to add to the X509Anchors keychain. I followed the instructions, but I did not find any X509Anchors Keychain under System > Library > Keychains on my Mountain Lion machine. –  D.W. Dec 6 '12 at 22:25

2 Answers 2

I looked into this a bit, and in my case the issue was on the RDP Server side. The certificate it was using was actually a self-signed, automatically generated one that was not signed by my local CA's root certificate. It thus didn't matter where I put the root cert, I always got the pop-up saying "The Certificate is not trusted..."

I installed the root cert from my local CA in the System keychain and set it to Always Trust, then on the Windows Server side, using Administrative Tools -> Remote Desktop Services -> Remote Desktop Session Host configuration, I updated the certificate assigned to the RDP-Tcp connection. Right-click RDP-Tcp Connection, choose Properties. On the General tab, see at the bottom there's a link labelled "Auto-generated"

(see an image of the pane here: http://www.windowsecurity.com/img/upl/image0021281709633474.jpg)

That's the self-signed certificate. Clicking Select lets you choose any other certificate already on the machine. Once that change was made, the prompt was gone from the client side on the next login.

Hope this helps (though it really only helps if you have admin access on the Windows side...)

share|improve this answer

Adding to the System keychain, set to "Always trusted", worked like a charm for me.

share|improve this answer

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

1  
This did not work for the OP however. –  gentmatt Dec 13 '12 at 13:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.