marius gabi wrote:
The certificate you posted in your previous messages doesn't use
unsupported signature algorithms as I was guessing previously.
Since its verify depth is "2" and it seems to be the root certificate,
I think the complete chain of the client certificate consists of three
certificates.
> Currently I'm facing an issue in a Server application that uses
> TSSLWSocketServer.
> I'm setting to the SSLContext a server certificate
> identified in code as SSLContext.SslCertFile, with the correct
> private key file identified as SSLContext.SslPrivKeyFile and a
> password.
Correct.
> Also I'm adding a CAFile identified as
> SslContext.SslCAFile.
What is the content of that file?
For instance if the server certificate chain consists of three
items:
[2] Root
[1] Intermediate_ServerCA signed by [2]
[0] SSL server certificate signed by [1]
You set [0] as the TSslContext.SslCertFile, as you did already.
Next create a CAFile that contains both [1] and [2]
(I think [1] has to be the first, however I always forget the order
in which they must appear, just play).
That way the entire chain is sent to the client, or at least [0] and [1].
You can check what's actually sent using WireShark since the connection
is still unencrypted.
> A client application sends a message and uses a X509 Certificate from
> the same CA as my own certificates.
Client certificate and server certificate are signed by the exact
_same_ certificate? I'm asking because only in such a case their
chains up to root are also the same, in which case my example
should work.
If client and server certificate have different chains the
TSslContext.SslCertFile itself should contain the chain of
certificates sent to the client, and CAFile the certicates
required to verify client certificates.
> 1. The
> client doesn't have a client version of my certificates
In the sample above the client must explicitly trust [2].
The client might or might not have [1] locally in his trusted
certificates. IF NOT, the server MUST send [1] during handshake
as well. That is achieved by adding intermediate certificates to
either to CAFile or use a certificate chain as the SslCertFile.
> (With my
> client certificate issued for me the communication works perfectly
> but this is not an option as project specification doesn't allow
> providing certificates to clients)
Sorry, I do not understand. Please explain again since that might
help to resolve your problem.
> 2. I have to use
> SslContext.SslVerifyPeer = True
> 3. I'm receiving the following message
> in the SSLVerifyPeer event: Error = 7 (certificate signature
> failure).
> The requirement is: if the client sends its own client
> certificate but has the same CA as my server certificate than the
> communication (client sends a message to server) should be possible.
That should work.
> I already tried to implement in the SSLVerifyPeer event so this
> method always returns true but with no positive outcome:
For debugging set "OK := 1;" in order to continue verification and to
log ALL events and certificates. Then post the log again.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
