marius gabi wrote:
> Thank you for your time!
>
> Indeed updating the OpenSSL version fixed my issue but the following
> strange thing happens: currently I am using ICS V7 but the highest
> version supported by my ICS is 0.9.8n and in this case the
> application still would not work OK.
What does
marius gabi wrote:
>> Here are the files with OK := 1;
>>
>> cert0 = Greatest CA (same as server's great CA)
>> cert1 = Intermediary CA (client's intermediary different from mine's
>> server) cert2 = Client certificate
Use at least OpenSSL version 0.9.8k from:
http://wiki.overbyte.be/wiki/index.p
marius gabi wrote:
> I have updated the SslHandshakeDone(Sender: TObject; ErrCode: Word;
> PeerCert: TX509Base; var Disconnect: Boolean); event as you mentioned
> and I used SslVerifyDepth = 15 and
> for I := 0 to TCustomSslWSocket(Sender).SslCertChain.Count -1 do
> TCustomSslWSocket(Sender)
marius gabi wrote:
> Arno, in this moment the client sends the entire certificates chain:
> 1. its client certificate issued by the intermediary CA (2 from
> bellow)
> 2. intermediary certificate issued by the root CA
> 3. root CA
OK.
>
> The only certificate that is common between our server c
Arno Garrels wrote:
> Usually all CA certificates issued by a root
> CA are available for download as well.
Correction: That is mostly true if they have been
issued to their own organizition.
> In your case the URL is
> http://sumo.irisa.fr/html/pki/ but their server currently fails
> with error
marius gabi wrote:
> Thank you for your prompt response. We already tried your solution
> and seems to be working. The issue is as follows: I do not have
> (access to) the client's certificate (application not developed by
> me) in order to compose the chains you mentioned.
You do not need client
marius gabi wrote:
> Thank you for your feedback.In my current scenario the certificate
> structure is as follows:
> Server(my application) | Client
> Root certificate -same as- Root certificate
> Intermediary CA-not same as- Intermediary CA
> Server Cert -not same as- Client Cert
>
Arno Garrels wrote:
> 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).
The best way to determine what certificates are sent to the peer
requesting certificate verification is to add th
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
certifica
ith:
Cert.GetRawText;
That would show you / us the *Signature Algorithm*.
Since there's a "certificate signature failure" it is my guess
that an unsupported algorithm is used.
--
Arno Garrels
> --- On Mon, 5/2/11, Arno Garrels wrote:
>
> From: Arno Garrels
> Sub
Arno Garrels wrote:
> marius gabi wrote:
>
>> I'm receiving the following message
>> in the SSLVerifyPeer event: Error = 7 (certificate signature
>> failure).
>
> In the OnSslVerifyPeer event please do the following logging and
> post the result:
>
> Log('Received certificate'#13#10 +
>
marius gabi wrote:
> I'm receiving the following message
> in the SSLVerifyPeer event: Error = 7 (certificate signature
> failure).
In the OnSslVerifyPeer event please do the following logging and
post the result:
Log('Received certificate'#13#10 +
'Subject: "' + Cert.Subje
12 matches
Mail list logo
