Re: Self-verifying names

[Sean Rhea]

On Nov 30, 2005, at 10:48 PM, Victor Duchovni wrote:

Clearly OpenSSL has already verified that the client
has a private key that matches the public key in the certificate, or
else all the certificace checks are pointless.

Are you SURE about that? I'm not doubting you, it's just that "Clearly..." sounds more like an assumption.

Why should it return NULL? If the client supplied a certificate,
and your verification callback in the server said it was OK (just
say yes), once the session is established check the public key.

The output, by the way, looks like this:

$ ./server
server: waiting for accept
server: tcp accept succeeded
server: ssl accept succeeded
client cert digest=c052b579972919c474e99604443ca0b6d50b215d
server: read 14 bytes
server: wrote 14 bytes
server: connection closed

$ ./client
client: tcp connect succeeded
client: ssl connect succeeded
server cert digest=3426940b3247899a536046b58d71a9f2900e63f9
Hello, World!




Thanks again for all your help,
Sean
--
           Humanity has advanced, when it has advanced, not because
           it has been sober, responsible, and cautious, but because
                 it has been playful, rebellious, and immature.
                                 -- Tom Robbins

Okay, I think I have that working. Three sample files are attached. The client and server sides, and a common verification routine. Would you mind looking them over and letting me know whether they're doing what I want? I THINK they are, but security-sensitive code can always use a second set of eyeballs. :) $ openssl x509 -fingerprint -in client-cert.pem -sha1 -nooutSHA1 Fingerprint=C0:52:B5:79:97:29:19:C4:74:E9:96:04:44:3C:A0:B6:D5:0B:21:5D $ openssl x509 -fingerprint -in server-cert.pem -sha1 -nooutSHA1 Fingerprint=34:26:94:0B:32:47:89:9A:53:60:46:B5:8D:71:A9:F2:90:0E:63:F9

client.C
Description: Binary data

server.C
Description: Binary data

common.C
Description: Binary data

PGP.sig
Description: This is a digitally signed message part