Schannel and client certificates

[Antony Perkov]

I wrote a library that PInvokes the Schannel SSPI provider to allow me to
make SSL/TLS connections from .Net 1.x code. This library has been operating
sucessfully in our production environment for about a year and a half now.

I have a new requirement to accept (and validate) client certificates. How
do I set things up so that client certificates are accepted, but optional?

If I call AcceptSecurityContext() with the ASC_REQ_MUTUAL_AUTH flag I can
retrieve client certs with QueryContextAttributes(). However
ASC_REQ_MUTUAL_AUTH seems to make client certs mandatory. What am I missing?

[Rhett Gong [MSFT]]

Hi Antony,
Yes, calling AcceptSecurityContext with ASC_REQ_MUTUAL_AUTH will have the
client's cert required. And so far as I know, there is no flag can be used
to optionally require the cert.
How are you going to determine whether the cert is required or not? Could
you explain a bit more on your scenario? So we can see if there is another
way for this problem. Thanks.

Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.

[Antony Perkov]

Ok some background details: My server implements an XML over TCP/SSL
protocol (defined in RFC 3730 - 3735). Authorization for this service is
based on user names and passwords passed across the wire in the XML body.
Additionally clients are supposed to be able to provide client certs which
have the effect of limiting the valid user names and passwords for the
session.

I was hoping that since we haven't required client certs up until now I
could make their use optional to avoid breaking existing clients.

As you can imagine since I'm implementing stuff defined in RFCs I don't
really have much room to design around any limitations of certain APIs etc.
Hopefully that isn't the problem here :)

IIS seems to support optional client certs (i.e. it supports three cert
options: "Ignore client certs", "Accept client certs", and "Require client
certs"). Does IIS not use SChannel?

Its not a show stopper if I can't use SChannel to support optional client
certs. Just slightly inconvenient. In that case do you know if the Whidbey
SslStream class will support optional client certs, or is it itself just a
wrapper around SChannel?

Thanks for your help so far.

"Rhett Gong [MSFT]" <v-ra...@online.microsoft.com> wrote in message
news:blB7NKRg...@cpmsftngxa06.phx.gbl...

[John Banes [MS]]

The mutual auth flag just tells AcceptSecurityContext to *request* a client
certificate when doing the SSL handshake. The function (and the handshake)
will succeed regardless of whether the client sends a certificate or not.

If the client sends a certificate then your subsequent QueryContextAttribute
call will succeed; otherwise this call will fail. What your code does based
on this bit of information determines whether client certificates are
"required" or not.

Regards,
John Banes
[Microsoft Security Developer]

This posting is provided "AS IS" with no warranties, and confers no rights.

Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"Antony Perkov" <Antony...@newsgroup.nospam> wrote in message
news:%23Nu1BIJ...@TK2MSFTNGP10.phx.gbl...

[Antony Perkov]

Ok the way you describe things below is how I had hoped things would work.
Perhaps the problem is with my client then...

When my server calls AcceptSecurityContext() with the ASC_REQ_MUTUAL_AUTH
flag, my client fails if I don't assign a certificate context in the
AcquireCredentialsHandle call.

Specifically I get an SEC_E_INCOMPLETE_CREDENTIALS ("The credentials
supplied were not complete, and could not be verified. Additional
information can be returned from the context") error on the 3rd call to
InitializeSecurityContext.

In case this helps: my client calls AcquireCredentialsHandle with the
SCH_CRED_NO_DEFAULT_CREDS flag, and InitializeSecurityContext with the
following flags: ISC_REQ_REPLAY_DETECT | ISC_REQ_SEQUENCE_DETECT |
ISC_REQ_CONFIDENTIALITY | ISC_REQ_STREAM | ISC_REQ_EXTENDED_ERROR.

Thanks for your help so far.

"John Banes [MS]" <jba...@online.microsoft.com> wrote in message
news:uEGqVYag...@tk2msftngp13.phx.gbl...

[John Banes [MS]]

When the SEC_E_INCOMPLETE_CREDENTIALS error is returned from
InitializeSecurityContext, your client code can do one of two things.

#1
It can find a client certificate, call AcquireCredentialsHandle to get a
cred handle containing the certificate, and call InitializeSecurityContext
again passing in the new cred handle. This will allow the handshake to be
completed, with the client certificate chain being sent to the server.

#2
It can skip finding a client certificate, and just call
InitializeSecurityContext back, passing in the ISC_REQ_USE_SUPPLIED_CRED
flag. This will tell schannel to send the client certificate associated with
the passed in cred handle, regardless of whether the cred handle actually
contains a client certificate or not. If the credential doesn't contain a
client certificate, then the handshake is completed without sending it.

Regards,
John Banes
[Microsoft Security Developer]

This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"Antony Perkov" <Antony...@newsgroup.nospam> wrote in message

news:%23yKk7R4...@TK2MSFTNGP10.phx.gbl...

[Antony Perkov]

Thanks for your help John,

That's fixed my issue.

Ant.

"John Banes [MS]" <jba...@online.microsoft.com> wrote in message

news:u5CHcO9g...@tk2msftngp13.phx.gbl...