Can SslStream be set to ignore invalid certificates?

microsoft.public.dotnet.security

1 Aug 2006 5:29 PM

Matthew Sawyer

Hi, I have an application that I originally wrote in .NET 1.1 and ported to
..NET 2.0. It is an instant messaging/presence client based on the XMPP
(Jabber) protocol and makes use of SSL in its communications with the server.
You can check out the client, USCSS Nostromo A7X, at
https://www.dojonorthsoftware.net/jmLambert, the Lambert Project homepage.

Because native SSL support was limited in .NET 1.1, I found the Mentalis.org
security library, which gave me everything I needed. Even better, it was
free to use and not even bound by the GPL.

This library continued to work in .NET 2.0, but when I saw that there is
much more SSL functionality in .NET 2.0, such as the SslStream, I wanted to
drop the use of the third party library and use native .NET functions.

I quickly ran into a roadblock with SslStream, however. Before you can do
anything with it, you have to authenticate (i.e. call AuthenticateAsClient).
If authentication succeeds, everything in the SslStream becomes
available...you can read, write, check flags, etc. If it fails, however, an
AuthenticationException is thrown and the SslStream is unusable.

The roadblock I ran into is this: if the SSL certificate possessed by the
server is in any shape, fashion or form "invalid," the authentication fails!
Some examples:

* Name on certificate doesn't match the supplied name.
* Certificate is expired or not yet valid.
* Certificate is self-signed.
* Certificate is signed by a trusted CA.

In IE, for instance, if you run across an "invalid" certificate, you are
told what the problem is and given the option to proceed anyway. With
SslStream, however, you don't appear to have this option. Either the
certificate is 100% perfect, or it's 100% bad. There's no "middle ground" or
option to "ignore" an invalid certificate.

In writing this application, I have no way of knowing who is going to
download it or what server they will connect to. Maybe the server will have
a self-signed certificate, or maybe the user doesn't have a trusted root CA
certificate.

Try to bring up https://jabber.org:5223 - this is a well-known, free public
Jabber IM service; you will note right away that the certificate is not
signed by a trusted root CA. Thus, calling myStream.AuthenticateAsClient(
"jabber.org" ); will fail miserably because the certificate will be
considered "invalid."

Is there any way to use an SslStream and still be able to use it even if the
certificate is deemed to be "invalid?" In other words, is it possible to
tell the SslStream to "ignore" invalid certificates and proceed anyway? If
Internet Explorer gives you the option to ignore bad certificates, you would
think SslStream would allow you to as well.

Best regards,
Matt

1 Aug 2006 6:28 PM

Dominick Baier

Hi,

check the following SslSteam ctor:

public SslStream (
    Stream innerStream,
    bool leaveInnerStreamOpen,
    RemoteCertificateValidationCallback userCertificateValidationCallback
)

the certificate validation callback allows you to do your own checking. You
will get a SslPolicyErrors enum passed into the callback and a X509Chain
object. Then you can check why validation would have failed and simply return
a true/false back....

If you need more help, i should have a sample around somewhere.

dominick

Show quoteHide quote

> Hi, I have an application that I originally wrote in .NET 1.1 and
> ported to
> .NET 2.0. It is an instant messaging/presence client based on the
> XMPP
> (Jabber) protocol and makes use of SSL in its communications with the
> server.
> You can check out the client, USCSS Nostromo A7X, at
> https://www.dojonorthsoftware.net/jmLambert, the Lambert Project
> homepage.
> Because native SSL support was limited in .NET 1.1, I found the
> Mentalis.org security library, which gave me everything I needed.
> Even better, it was free to use and not even bound by the GPL.
>
> This library continued to work in .NET 2.0, but when I saw that there
> is much more SSL functionality in .NET 2.0, such as the SslStream, I
> wanted to drop the use of the third party library and use native .NET
> functions.
>
> I quickly ran into a roadblock with SslStream, however. Before you
> can do anything with it, you have to authenticate (i.e. call
> AuthenticateAsClient). If authentication succeeds, everything in the
> SslStream becomes available...you can read, write, check flags, etc.
> If it fails, however, an AuthenticationException is thrown and the
> SslStream is unusable.
>
> The roadblock I ran into is this: if the SSL certificate possessed by
> the server is in any shape, fashion or form "invalid," the
> authentication fails! Some examples:
>
> * Name on certificate doesn't match the supplied name.
> * Certificate is expired or not yet valid.
> * Certificate is self-signed.
> * Certificate is signed by a trusted CA.
> In IE, for instance, if you run across an "invalid" certificate, you
> are told what the problem is and given the option to proceed anyway.
> With SslStream, however, you don't appear to have this option. Either
> the certificate is 100% perfect, or it's 100% bad. There's no "middle
> ground" or option to "ignore" an invalid certificate.
>
> In writing this application, I have no way of knowing who is going to
> download it or what server they will connect to. Maybe the server
> will have a self-signed certificate, or maybe the user doesn't have a
> trusted root CA certificate.
>
> Try to bring up https://jabber.org:5223 - this is a well-known, free
> public Jabber IM service; you will note right away that the
> certificate is not signed by a trusted root CA. Thus, calling
> myStream.AuthenticateAsClient( "jabber.org" ); will fail miserably
> because the certificate will be considered "invalid."
>
> Is there any way to use an SslStream and still be able to use it even
> if the certificate is deemed to be "invalid?" In other words, is it
> possible to tell the SslStream to "ignore" invalid certificates and
> proceed anyway? If Internet Explorer gives you the option to ignore
> bad certificates, you would think SslStream would allow you to as
> well.
>
> Best regards,
> Matt