Why are you using the same file for both your Certificates and your
list of CA Certificates to validate incoming certificates with? When a
client passes you their certificate, nsopenssl uses the CA certificates
in the CAFile to validate that client certificate. Based on what I see
below, you're using your own certificate as if it were a CA
certificate, which means you'll never be able to validate any
certificates.

SockServerCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem
SockServerKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem
SockServerCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem

SockClientCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem
SockClientKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem
SockClientCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem

Secondly, nsopenssl does not abort a connection because of invalid certs -- it just logs them. Your response to the invalid cert is your application's responsibility. The reason is that you might want to return a useful error page to the user or application on the other end; if you barf on the SSL handshake, the user gets whatever error page the browser generates because no content ever passes between the two.

Based on your output here:

20/Jan/2004:12:26:49][93990.135948288][-conn1-] Notice: nsopenssl:
sockclient:
SERVER's CERT is NOT VALID
[20/Jan/2004:12:26:51][93990.135948288][-conn1-] Notice: nsopenssl:
trace:
sockclient: SSL negotiation finished successfully; alert type =
warning; alert
desc = close notify
[20/Jan/2004:12:26:51][93990.135948288][-conn1-] Notice: nsopenssl:
trace:
sockclient: SSL negotiation finished successfully; alert type =
warning; alert
desc = close notify
[20/Jan/2004:12:26:51][93990.135948288][-conn1-] Error: Ns_PgExec:
result
status: 7 message: ERROR:  ExecAppend: Fail to add null value in not
null
attribute transaction_id

[20/Jan/2004:12:26:51][93990.135948288][-conn1-] Error: Wasn't able to
do insert
into ezic_gateway_result_log for transaction_id ; error was Database
operation
"dml" failed

The SSL handshake completes successfully, meaning that you have established a good SSL connection. Your problem is the database operation. Without seeing the schema and code, can't really say much about that.

/s.


-- AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Reply via email to