Error 12015/SSL+Digest

[a***@cs.com]

Having a problem while accessing the site (Apache server) over SSL
with Digest authentication.

WinHttpReceiveResponse() returns error 12015 without an attempt to
authenticate. Normally, I would expect to see 401 response, after
which I use WinHttpSetCredentials() and re-send. Auto-logon policy is
set to HIGH.

I did the trace and can see that the server returns a normal Digest
challenge. I also can see that the initial request does not contain
any authorization header. However, I am getting error 12015, as I
would try to authenticate.

I tried to ignore that error, set credentials, and re-send over the
same request handle. No authorization headers are sent. Same error
12015.

When I disable automatic authentication, the first request returns
401, as expected. However,
WinHttpQueryAuthSchemes() fails. And manual push for
WinHttpSetCredentials() doesn't help.
This is, perhaps, because of the automatic authentication option
disabled. So, the communications really look like an attempt to
authenticate at the first request.

Any help would highly appreciated.

[Oliver]

Post by a***@cs.com
Having a problem while accessing the site (Apache server) over SSL
with Digest authentication.
WinHttpReceiveResponse() returns error 12015 without an attempt to
authenticate. Normally, I would expect to see 401 response, after
which I use WinHttpSetCredentials() and re-send. Auto-logon policy is
set to HIGH.
I did the trace and can see that the server returns a normal Digest
challenge. I also can see that the initial request does not contain
any authorization header. However, I am getting error 12015, as I
would try to authenticate.
I tried to ignore that error, set credentials, and re-send over the
same request handle. No authorization headers are sent. Same error
12015.
When I disable automatic authentication, the first request returns
401, as expected. However,
WinHttpQueryAuthSchemes() fails. And manual push for
WinHttpSetCredentials() doesn't help.
This is, perhaps, because of the automatic authentication option
disabled. So, the communications really look like an attempt to
authenticate at the first request.
Any help would highly appreciated.

Ignoring the 12015 error and going on with authentication will most
probably do no good. Even the error documentation in MSDN reads "The login
attempt failed. When this error is encountered, the request handle should
be closed with WinHttpCloseHandle. A new request handle must be created
before retrying the function that originally produced this error."

1) If you set the Autologon Policy to high, an Auto-logon will only be
attempt by WinHTTP if the server (or proxy) is in the intranet. Another
precondition is that NTLM or Negotiate authentication is offered by the
server/proxy as the Autologon of WinHTTP applies to no other
authentication methods.
- Is the server is in the intranet?
- Does it offer other authentication methods than Digest?
If your answer is yes to both questions, I even expect the WinHTTP trying
to auto-logon.
- Is the server properly configured to accept your Windows domain login
credentials?
If not, the WinHTTP is right issuing the 12015 error.

So as long as you do not want to auto-logon to servers or proxies in your
intranet that accept your domain credentials by NTLM or Negotiate
authentication, you should consider disabling the Autologon completely.
It's not what you want.


2) When you disable the Autologon and get the 401:
- Can you please post the challenge headers?
- What is the Windows error code of the WinHttpSetCredentials?

If you have the server certificate, you can setup Wireshark to capture the
decrypted network traffic.
If you do not have the server certificate, consider using Fiddler which
plays kind of Man-in-the-Middle to capture the decrypted network traffic.
- It would be good to see the decrypted network trace.

[a***@cs.com]

Thanks for reply.

I do understand all that you said about auto-logon. I did this in
attempt to investigate the problem.
The target server is NOT on intranet. I tried to avoid any possibilty
for auto-logon.

I did the trace and this is what I see:

Request headers:
===============
POST /xml HTTP/1.1
Accept: */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/xml
Accept-Encoding: gzip
Host: denver.pbx.onyxmd.com
Content-Length: 120
Connection: Keep-Alive

Response headers:
================
HTTP/1.0 401 Authorization Required
Date: Sat, 22 Jan 2011 07:05:29 GMT
Server: Apache/2.2.3 (Fedora)
WWW-Authenticate: Digest realm="switchvox_api_auth",
nonce="49a69fdf089db"
Set-Cookie: lang_locale=en_us; path=/
Connection: close
Content-Type: text/html; charset=UTF-8


That's it. On receipt, WinHTTP elects to close the connection. I can
see the RESET TCP packet
sent from my side. No authentication attempt. Error 12015 is returned
on WinHttpReceiveResponse().

Looks like it does not understand (or doesn't like) WWW-Authenticate
header? It is not
exactlly according to RFC for Digest, but still looks OK to me. By
the way, this works fine from
IE (WinInet).

Any ideas?

[a***@cs.com]

Just emulated this server locally. SSL doesn't matter.
WinHTTP does not like the format of "WWW-Authenticate"
header.

When I add "qop" token to the challenge header, everything
works. When I remove it, I get error 12015.

How this can be??? Isn't it optional?

[Oliver]

Post by a***@cs.com
Thanks for reply.
I do understand all that you said about auto-logon. I did this in
attempt to investigate the problem.
The target server is NOT on intranet. I tried to avoid any possibilty
for auto-logon.
===============
POST /xml HTTP/1.1
Accept: */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/xml
Accept-Encoding: gzip
Host: denver.pbx.onyxmd.com
Content-Length: 120
Connection: Keep-Alive
================
HTTP/1.0 401 Authorization Required
Date: Sat, 22 Jan 2011 07:05:29 GMT
Server: Apache/2.2.3 (Fedora)
WWW-Authenticate: Digest realm="switchvox_api_auth",
nonce="49a69fdf089db"
Set-Cookie: lang_locale=en_us; path=/
Connection: close
Content-Type: text/html; charset=UTF-8
That's it. On receipt, WinHTTP elects to close the connection. I can
see the RESET TCP packet
sent from my side. No authentication attempt. Error 12015 is returned
on WinHttpReceiveResponse().
Looks like it does not understand (or doesn't like) WWW-Authenticate
header? It is not
exactlly according to RFC for Digest, but still looks OK to me. By
the way, this works fine from
IE (WinInet).
Any ideas?

I'm wondering why the challenge is HTTP/1.0 with Connection: close, but
I'm not that deep into Digest authorization to tell whether this is ok -
it probably is.

Did you test whether your program runs into the same error on Windows 7
and Windows XP?