Re: TLS Handshake issue
- From: "Jos Scherders" <thrower@xxxxxxx>
- Date: Wed, 14 Mar 2007 23:43:27 +0100
Hi Raghu,
Thanks for responding to my post. What you describe is exactly was is
happening. We pass
ISC_REQ_MANUAL_CRED_VALIDATION and do the validation ourselves (althought
I am
not sure why we do this at this moment). Do you know what checks the
SChannel performs
on the server certficate if I do not supply the MANUAL_VALIDATION flag ?
One thing I don't understand though. Why can't I verify the server
certificate and then sent my client certificate ?
As I understand the protocol, the server information including the
certificate is sent first and only then do
I need to sent my certificate. So, it should be possible to get the
certificate from the buffers received, check it, and
then continue the handshake by supplying my cert. Is this not supported by
SChannel ?
Also, can I sent some sort of an alert to the server with the reason of the
abort or is this not possible. This is
what the server expects apparently (I am testing if we comply with a Health
Care Security Profile w.r.t to handling of
certificates).
Jos.
"Raghu Malpani" <rmalpani@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:A43357C0-55E8-4F37-81E8-F7871DDFF4A2@xxxxxxxxxxxxxxxx
If you did not pass in ISC_REQ_MANUAL_CRED_VALIDATION to the
InitializeSecurityContext call, then Schannel (SSPI package that
implements
TLS) will validate the server certificate for expiration for you and you
should get SEC_E_CERT_EXPIRED if the server cert is expired. You could
deal
with this error by simply closing the connection.
However, if you passed ISC_REQ_MANUAL_CRED_VALIDATION, then it is up to
you
to Query for the server's cert and validate it. Typically, this is done
after
the handshake is succesful. If you would not like to send the client
certificate without validating the server cert, you could pass in
ISC_REQ_USE_SUPPLIED_CREDS to schannel (To prevent it from picking a
client
cert automatically). This will force schannel to send an empty cert to the
server and the server may abort the connection. At this point, however,
you
should be able to validate the server certificate. If you like the
server's
cert, you could create a new connection only this time passing in the
proper
client certificate.
HTH.
"Jos Scherders" wrote:
Hi all,
I am doing maintenance on a TLS library which fails to notify the server
when an expired certificate is used. I am having trouble figuring out how
(and when) I should terminate
If I call QueryContextAttributes before InitializeSecurityContext()
returns
SEC_E_OK
I get an error message. If I call QueryContextAttributes after
InitializeSecurityContext() returns SEC_E_OK it works fine but at this
moment I already sent my client certificate. ?
This is where I am confused. Per the TLS spec I should check the server
certificate before I sent my own client certificate and fail the
connection.
Does anyone know what is going on here ?
What is the proper way of terminating the TLS handshake when I detect
that
the server certifcate is invalid. All I can find is that the client
should
warn the user and terminate. But what does terminate mean ? Should I just
shutdown the TLS connection or should I sent a TLS alert ?
Thanks for any help,
Jos
.
- References:
- TLS Handshake issue
- From: Jos Scherders
- TLS Handshake issue
- Prev by Date: how to export pfx programmatically
- Next by Date: Re: how to export pfx programmatically
- Previous by thread: TLS Handshake issue
- Next by thread: Re: TLS Handshake issue
- Index(es):
Relevant Pages
|