Can't connect to cert-requesting servers without client cert

[steffengy]

Can't connect to cert-requesting servers without client cert

[jethrogb]

This can be fixed by passing in winapi::ISC_REQ_USE_SUPPLIED_CREDS to InitializeSecurityContextW in TlsStream::step_initialize. Possibly in a second call in response to the SEC_I_INCOMPLETE_CREDENTIALS error. Is its non-use intentional? Not setting the flag will automatically use the system's client certificates without programmer interaction.

[steffengy]

AFAIK there isn't a reason it is not passed in.
(except maybe suboptimal documentation)

1.)

The only thing I was worried about is that we guarantee
that added certificates are considered for client authentication.

After reading some nested layers of documentation, the only thing this flag seems to change
for that is that it reduces the search scope to the certificates linked to the handle
acquired by AcquireCredentialsHandle.
So in my opinion this exactly does what we want.

2.)

From a users perspective it might be strange to get a terminated connection
from the server (when it requires a certificate but none was specified).
Not sure about a good way to improve the ergonomics here.

@sfackler

[jethrogb]

From a users perspective it might be strange to get a terminated connection
from the server (when it requires a certificate but none was specified).

It is up to the server to terminate the connection. If it asked for a cert, but didn't get one, the server can decide to proceed as normal or abort.

[steffengy]

It is up to the server to terminate the connection. If it asked for a cert, but didn't get one, the server can decide to proceed as normal or abort.

That's exactly the point.
A user of this library in this case cannot determine that the server aborted
because of a missing certificate (and mitigate that by specifying one and retrying).

It could presume that but the server going offline, a firewall dropping the request, ...
would look the same.

To recap: The issue is an issue of ergonomics: It might happen that someone
notices a mysterious bug where the server terminates the connection.
After several hours of work and troubleshooting this someone notices that the
actual issue is a not specified client certificate.

==> The termination cause is not transparent to the user. It's hidden
and exposed as a very generic - clearly unhelpful - error for that case.

[jethrogb]

Technically, in such a case the server is to send a handshake_failure TLS alert. At least in principle, this would be distinguishable from other network-related failure modes. Whether this happens in practice and whether that level of error makes it back to the user, I don't know.