Sorry I didn't get to this yesterday Patrice. You guessed the problem correctly - a "self-signed SSL certificate" will crash a .NET remoted application. It is not obvious that you need to install all of the certificates (typically there are 2 certs - the Root Authority and the server) of the "Certification Path" onto the client computer.

All authentication must be transparent to the operating system in .NET remoting.

What does this mean ?

    - .NET remoting does not allow any interception of the client's communication to the server ( it considers this a security breach )

    - the client application will fail if any message box or dialog box appears requesting credentials (login box) or confirmation to continue connection (unknown SSL certificate publisher)

        and the only way to avoid this is by utilizing "pass-through" or "transparent" authentication, such as Windows Integrated, to the proxy server or in the case of SSL: use a certificate which is automatically recognized by the operating system, such as a Verisign SSL certificate

    - .Net remoting can also fail if authentication is performed by a third-party application, such as a proxy/firewall/Internet Security application, which only provides transparent authentication to certain processes or applications and not to the entire operating system

Most of the time, you can tell if the client computer is using some type of pass-through authentication when the Internet browser is able to connect (download a webpage) without a login box or warning box appearing during the browser application startup.

Test the Client Computer: If you install the certificates correctly on the client computer, you should be able to browse a webpage on the test server using SSL (https://) without a security warning message box appearing.