--- Begin Message ---
On Wed, 2005-09-28 at 14:12, Sebastien Pouliot wrote:
> Hello Yngve,
>
> On Wed, 2005-28-09 at 11:42 +0200, Yngve Zackrisson wrote:
> > Hello Sebastien,
> >
> > Things seems to go better for me,
>
> great :)
>
> > but I still have problems
> > with my server side (Mono) authentication and decryption.
> > I now use a PKCS#12 file on my server side.
> > Se below for more info.
>
> ...
>
> > > > For the authentication probably an custom channel have to be used.
> > >
> > > I don't see why this would be required (for client-side certificates) as
> > > the authentication is part of the protocol itself.
> > >
> >
> > OK. Maybe I do not need this.
> > I just read some articles/samples at msdn about
> > .NET Remoting Authentication
> > and those articles suggested a custom channel.
> > (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/remsspi.asp
> > and
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/remsec.asp
> > and
> > http://msdn.microsoft.com/msdnmag/issues/03/06/NETRemoting/default.aspx
> > ).
> > The examples was about other forms of authentication (Kerberos etc)
> > and encryption so these references may not apply?.
>
> I don't think you'll need that unless you have some additional (more
> than the client certificate) authentication data.
>
> ...
>
> > We intend to sign both our server and client certificates
> > with our own root CA.
> > There is already unix scripts for this using openssl,
> > hence the preference for openssl.
>
> Ok, so you'll have a single root CA signing both your server and client
> certificate. This root certificate will have to be in the Mono's Trusted
> store on the server.
>
> ...
>
> > > > Binary formating shall be used.
> > >
> > > Was there a specific reason for using https and a binary formatting ? If
> > > I understand correctly you'll be supplying your own server software ? so
> > > you _could_ use SSL without using HTTP(S).
> >
> > Firewalls.
>
> Ok, so it's a port issue (not a protocol issue).
>
> > > > The server is in house and should be a Linux one.
> > > > We use latest version on Mono (1.1.9).
> > >
> > > Is the server software using Mono.Security.dll ?
> > > or is it using (vanilla or custom) XSP ?
> >
> > Currently Mono.Security.dll.
> >
> > The intention is to run the services as "Windows services" in Mono,
> > if that works.
>
> Remember that if the Mono service runs under another identity then the
> trusted root certificate must either be (a) in that user Trust store or
> (b) in the machine Trust store.
>
> > I have not got into this yet, so we might have to shift.
> > Currently I host the remote objects in a console application.
> >
> > >
> > > > The clients are Win32 clients using MS .NET
> > > > (v1.0 or v1.1 with SP enough to handle the certificates).
> > > >
> > > > The clients are not connected all the time, but only during
> > > > initialization and zip file transfer.
> > > >
> > > > The installation on the client side should be as simple as possible
> > > > for the clients.
> > > > Hence, preferable PKCS#12 client certificates should be used
> > > > and it should preferable be stored only in one file or in one store
> > > > (Windows store).
> > >
> > > You'll either have to :
> > >
> > > (a) write your own glue (p/invokes) if you want Mono.Security.dll to
> > > co-exists with Windows certificate stores;
> > >
> > > (b) completely skip Mono.Security.dll on the client side. I.e. once
> > > installed "correctly" the MS runtime should be able to "find" the
> > > private key matching the certificate you use in HttpWebRequest.
> >
> > OK. I have gone for (b).
> >
> > First I set the ServicePointManager.CertificatePolicy
> > to an custom class to detect any certificate errors.
> >
> > Then I use a DLL from Mentalis (Org.Mentalis.Security.dll)
> > to extract the client certificates from the Windows store,
> > and then select on the IssuerName.
> > Once that done, I use the Mentalis Certificate.ToX509() method
> > to convert to X509Certificate(s).
> > (See: http://www.mentalis.org/ and
> > http://www.mentalis.org/soft/projects/certificates/ ).
> >
> > Last I create the HttpWebRequest,
> > Add the X509Certificate(s) the requests ClientCertificates
> > and set the WebResponse to the HttpWebRequest.GetResponse().
> > It seems to work (on the client side).
> > No more "Untrusted root", since the certificates
> > is in the Windows store now.
>
> That's ok.
>
> > Other options for extracting the certificate(s)
> > from the Windows store seems to be:
> >
> > Using CryptoAPI calls:
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;895971
> >
> > Using a CAPICOM wrapper:
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncapi/html/netcryptoapi.asp
> >
> > Using WS-Security with the Web Service Developement Kit:
> > http://www.codeproject.com/csharp/cryptography.asp
>
> Yes, they are the other options.
>
> > > > As a first step, I would like to have the HttpWebRequest
> > > > and HttpWebResponse to work toghther with HTTPS.
> > >
> > > MS version of HttpWebRequest.ClientCertificates will "try to find"
> > > private keys (in it's store) associated with the certificate(s) you're
> > > supplying.
> > >
> > > Note that you may have problems if the client application runs on
> > > another identity (e.g. services runs as SYSTEM).
> >
> > OK. (Seems no problem for me).
> >
> > >
> > > Then, on the server side, you'll get this certificate (from
> > > SslServerStream) and you can validate it (with your own code) and decide
> > > what to do next...
> >
> > Here I still have problems.
> >
> > I have created a mssslserver2.exe based on your mssslserver.exe.
> > The difference is that mssslserver2.exe uses
> > a PKCS#12-filename and a password as arguments,
> > instead of a .cer-filename and .pvk-filename.
> > I have change the internals accordingly.
> >
> > When I run this program with:
> >
> > $ mono --debug --verbose mssslserver2.exe server16-cert.p12 'password'
> >
> > and call this with my client HttpWebRequest,
> > I got this error message on my server:
> >
> > error #-2146762486
> >
> > meaning a CERT_E_CHAINING problem
> > (also: X509ChainStatusFlags.UntrustedRoot
> > and AlertDescription.UnknownCA).
> >
> > I am pretty sure I have the right cert, key and CA in the .p12 file.
> > It seems that the root CA could not be found if it is in a PKCS#12 file.
>
> The root can (very probably) be found in the PKCS#12 file. However it
> _cannot_ be trusted *unless* it's installed in the Trust store.
>
> > Should I add a PKCS#12 cert file to the Mono Store (Machine store)
> > (mono /.../certmgr.exe -add -c -m Trust server16-cert.p12)
> > or add only the CA to the trust store
> > (mono /.../certmgr.exe -add -c -m Trust cacert16t.cer)
> > or anything else to get rid of this error message?.
>
> It must be either the user or machine Trusted store (otherwise you'll
> get a trust error).
OK. But witch certificate is preferable to add to the store?:
a) mono /.../certmgr.exe -add -c -m Trust server16-cert.p12
or
b) mono /.../certmgr.exe -add -c -m Trust cacert16t.cer
I also have a question about the trust of the root CA certificate.
The cacert16t.cer above I have created with the following
openssl commands:
...
$ openssl x509 -in cacert16.pem -trustout -setalias "TrustedRootCert"
-out cacert16t.pem
$ openssl x509 -inform PEM -in cacert16t.pem -outform DER -out
cacert16t.cer
is the first openssl command necessary since the signed client
and server certificates, or at least its root CA,
should be added to the Windows/Mono (Trust) store?.
Currently I use the cacert16t.pem file as -certfile
when creating the client and server PKCS#12 files -
with the openssl pkcs12 command.
Will the cacert16.pem file be enough?
>
> > On the server I get an exception during the client call
> > (in: reader.ReadLine ()) below:
> > >>>
> > ...
> > using (SslServerStream s = new SslServerStream (ns, Certificate, true,
> > false)) {
> > ...
> > StreamReader reader = new StreamReader (s);
> > ...
> > string line;
> > // Read request header
> > do {
> > line = reader.ReadLine ();
> > ...
> > <<<
> >
> > The exception goes like this:
> > >>>
> > EXCEPTION handling: TlsException
> > EXCEPTION handling: TlsException
> > EXCEPTION handling: IOException
> > EXCEPTION handling: IOException
> > ---------------------------------------------------------
> > System.IO.IOException: The authentication or decryption has failed. --->
> > Mono.Security.Protocol.Tls.TlsException: Handshake Failure.
> > in <0x00134>
> > Mono.Security.Protocol.Tls.Handshake.Server.TlsClientCertificateVerify:ProcessAsSs3
> > ()
> > in <0x00057>
> > Mono.Security.Protocol.Tls.Handshake.HandshakeMessage:Process ()
> > in (wrapper remoting-invoke-with-check)
> > Mono.Security.Protocol.Tls.Handshake.HandshakeMessage:Process ()
> > in <0x00084>
> > Mono.Security.Protocol.Tls.ServerRecordProtocol:ProcessHandshakeMessage
> > (Mono.Security.Protocol.Tls.TlsStream handMsg)
> > in <0x00239>
> > Mono.Security.Protocol.Tls.RecordProtocol:InternalReceiveRecordCallBack
> > (IAsyncResult asyncResult)--- End of inner exception stack trace ---
> >
> > in <0x000d4>
> > Mono.Security.Protocol.Tls.SslStreamBase:AsyncHandshakeCallback
> > (IAsyncResult asyncResult)
> > <<<
> >
> > I guess that this has to do with the CERT_E_CHAINING problem
> > mentioned above. Possible?. Right?
>
> Maybe but I don't think so.
>
> Yesterday (after your previous email) I tried to use the MS runtime for
> client certificate without success (same failure). Somehow MS does
> something different* because the server can't verify the signature (and
> it's not a key and/or decryption problem - the hash value is different
> but the padding is ok).
>
> Using IE (with the SSL2 client hello) to do the same turned out another
> problem, very similar to the bug #76254 reported today.
>
> [*] The client certificate testing is done with wget/openssl
> (linux/cygwin) - which sadly doesn't seems enough :(
Please let me know if you come up with some solution.
I have been working with the HTTPS communication for some 2 months now,
and my boss is eager to get an solution :-).
Regards
Yngve Zackrisson.
--- End Message ---
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
