When I attempt to connect my SSL client (using SecureTCPClient) to an OpenSSL server everything seems OK until I try to write to the socket. I am using a certificate I received in a PEM file which alledgedly has a password.

I cannot find a place to put the password when I load the certificate (is this a portential source of the error?). The server fails in the negotiation of the connection.

My write gets an IO exception with the following description:

"Cannot access a disposed object named \"Org.Mentalis.Security.Ssl.Shared.SocketController\"."

The code I am running is pretty basic:

Certificate cert = Certificate.CreateFromPemFile("F:\\client.pem");

options = new SecurityOptions(SecureProtocol.Ssl3,cert,ConnectionEnd.Client);

m_client_port = new SecureTcpClient(options);

m_client_port.Connect("10.207.101.40",16001);

m_client_port.GetStream().Write(buffer,0,11);

Any help would be greatly appreciated.

Thanks
Daryn

As the documentation of the CreateFromPemFile states: "this implementation only reads certificates from PEM files. It does not read the private key from the certificate file, if one is present."
The password is used to encrypt the private key, but since our implementation currently does not read the private key, it does not require a password. Future versions of the library will be able to read the private key from a PEM file.

To get around this problem, you can convert your PEM file to a PFX file; OpenSSL can do this for you:
openssl pkcs12 -export -in certificate.pem -out certificate.pfx -name "My Certificate"

If you do not have a compiled OpenSSL library, let me know and I'll send you one.

Thansk for the quick response.

I just regenerated the key as a pfx using the command you mentioned but am getting the same error. The code now looks like:

Certificate cert = Certificate.CreateFromPfxFile("F:\\client.pfx","igtigt");

options = new SecurityOptions(SecureProtocol.Ssl3,cert,ConnectionEnd.Client);

m_client_port = new SecureTcpClient(options);

m_client_port.Connect("10.207.101.40",16001);

m_client_port.GetStream().Write(buffer,0,11);

Are you sure the server has a valid certificate? The SecurityOptions instance you're using has its VerificationType field set to CredentialVerification.Auto. This means that, if the certificate validation fails for any reason [unknown root, invalid common name, etc.], the SecureSocket will be automatically closed.
Try setting it to CredentialVerification.None; if the connection succeeds you know it's a certificate problem.
We suggest setting the verification type to Manual.

The certificate is valid with the exception of the CN. I have changed the verification type to "AutoWithoutCName" and it does not work. I have another client written with IP*WORKS that uses the same certificate file and will work if I disable CName verification.

I've uploaded a new version of the security library [1.0.13.670] that fixes a few problems in the SSL/TLS code.
Can you try the new version to see if it works now?

Pieter,

The new code worked as expected. Thanks for the quick turn around. 1 last question, how can I tell when a connection is completed and the status of the connection from a SecureTcpClient?

That's great to hear.

What do you exactly mean with "when a connection is completed"? When the SSL/TLS handshake is finished?
If so, there's currently no way to know when the handshake is finished because this has to do with the internal workings of the SecureSocket and we didn't think anyone would need it.
As soon as you've called the Connect() method of a SecureSocket instance, you can start sending and receiving your data. If you send data and the SecureSocket is in the middle of a handshake, it will put your data in a queue and wait until the handshake is complete.

Ok, that works for me. However, I did notice when I was having my issues that the CanWrite of the underlying SecureStream was true, but the connection had failed internally...