Fantastic response, just what I needed, thanks Kyle.

Now, I have done as you suggested:

The s_server tests showed a perfect XML message in the s_server window,
so that seems fine.

The s_client test I assumed I had to run in a separate session whiles
the s_server command was still running - output looked like this:

----------------------------------------------------------------
CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=Lee.Datadialogs.local
   i:/CN=RootCA
 1 s:/CN=RootCA
   i:/CN=RootCA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICUzCCAbygAwIBAgIBAjANBgkqhkiG9w0BAQQFADARMQ8wDQYDVQQDEwZSb290
Q0EwHhcNMDYwMjA4MTE0MjA4WhcNMDcwMjA4MTE0MjA4WjAgMR4wHAYDVQQDExVM
ZWUuRGF0YWRpYWxvZ3MubG9jYWwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AOWya4PAjZVC/1gTDJbC0RX0POdZ5umrrQDTbHiQXuA+uyJ7yYGOr9XIX1SSnDs7
H6+x7ljrVplxuzoP6cdyqnNJEmQcLwCDDk5t7j02rh1dsU8OyVrvRK5W7E4D1Gsy
1tX68hr7wCgPfQ264E1ys7C4t4V1E1rOmpTd+UMkBbzRAgMBAAGjgaswgagwDAYD
VR0TAQH/BAIwADAdBgNVHQ4EFgQUW5ofzwMKtZErCVSFecubNGop+RUwOQYDVR0j
BDIwMIAUhXyTyG8LFBeIF3l6jdcxM5r9tFuhFaQTMBExDzANBgNVBAMTBlJvb3RD
QYIBATALBgNVHQ8EBAMCBeAwEQYJYIZIAYb4QgEBBAQDAgZAMB4GCWCGSAGG+EIB
DQQRFg94Y2EgY2VydGlmaWNhdGUwDQYJKoZIhvcNAQEEBQADgYEAkH+BLke1qgA+
WjnC/F93ms/ytUuPomnblcS3E2JqMI5rwxnmLom8qAOLAm/txf3s7LImh7FhkVtg
jzLL3nDQv2eKzaptWMQOlH5dukwefkDW+S8uITr8+sPN/Ceq8uQrAHq6vrUt7N7j
qoEJ9CLDwRIIPE3VaP6ssJIO+9pFzNQ=
-----END CERTIFICATE-----
subject=/CN=Lee.Datadialogs.local
issuer=/CN=RootCA
---
Acceptable client certificate CA names
/CN=RootCA
---
SSL handshake has read 1658 bytes and written 1651 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID:
7D78ADC5D7EC3F0C2A8FE03ED5C512C7DE7A888E5B0352423990802396CCC435
    Session-ID-ctx: 
    Master-Key:
A52E61547ADD19440F7C8E27CCCE6AC8EFD0D5553B225E215892B599B1149C8F07B6B714
F45326564A14DD8B59308E3A
    Key-Arg   : None
    Start Time: 1139411553
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
----------------------------------------------------------------

Which seems fine - from then on, whatever I typed in the client window
appeared in the server window, so this is ok too by the sound of it.

One thing you did mention - ' manually generate some valid queries and
valid
answers to those queries' - did you mean manually code some soap
messages and pass them to s_client, to see what the server returns?  No
problem doing this, but how do I get them into s_client?

Thanks again, you've been a lifesaver.

Lee.



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle Hamilton
Sent: 08 February 2006 14:28
To: openssl-users@openssl.org
Subject: Re: Decryption question

In order for a certificate to have any meaning, it must include a
public key (of whatever type), and the private key should be kept
private for that side.

Thus, you've created three keypairs: one for the CA, one for the
server, one for the client.

The CA's certificate is self-signed, and you've given that certificate
to both the server and the client.

The server's certificate is signed by the CA, and you've given it to the
server.

The client's certificate is signed by the CA, and you've given it to the
client.

Okay.  Now, I understand what you're trying to do -- you're trying to
use SOAP in place of DCOM [which, btw, I applaud :)].  There's a whole
bunch of things that can go wrong on either side -- this is where the
openssl command-line program comes in handy.

What you want to do is manually generate some valid queries and valid
answers to those queries, because what you're going to do is fake the
server, and then fake the client.  To fake the server, get the server
cert and key out and put it into a new directory, name it server.pem,
copy the CA cert to the new directory, name it CA.pem, and then type
the following: 'openssl s_server -accept (portnum) -crlf -cert
server.pem -CAfile CA.pem'  (obviously, you want to replace portnum
with the actual port you're trying to use -- MAKE SURE THAT NOTHING
ELSE IS LISTENING ON IT, OR YOU WILL GET AN ERROR).

Then, use the client to connect to it, and send a request.  If it
comes through properly (i.e., you can read it), the client is
respecting the certificate that the server is sending.  Hit ctrl-c to
stop the server, and then do the same line, except append '-Verify
CA.pem' to the end of it, and then perform the test again.  If it
comes through, then it's not an SSL problem on the client or server
end, and you will have to look at gSOAP for the answer.

To test what the server is sending back to the client, you use almost
the same command, except it's: 'openssl s_client -connect
hostname:port -verify CA.pem -cert client.pem -crlf -CAfile CA.pem'

If you send a valid request via that mechanism, and it's logged as a
valid request on the server side, then your problem is in your
application (or, more specifically, its SOAP client library).

I hope this helps you troubleshoot it. :)

<snip>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to