WinHTTP in ASP: "A security error occurred"
Jon Little
certificate. The certificate is installed on the local server, and appears
to be found OK with the SetClientCertificate method.
But we get the message "A security error occurred" on the Send method.
The script is as follows:
<%
Dim obj
set obj = Server.CreateObject("WinHttp.WinHttpRequest.5")
obj.Open "POST", "https://xxx.yyy.zz/dir1/dir2/dir3l/targetscript.asp"
obj.SetRequestHeader "Content-Type", "application/x-www-form-urlencoded"
obj.SetClientCertificate "LOCAL_MACHINE\Root\aCertificate"
obj.Send "formData1=aaaa&formData2=bbbb"
Response.Write("#" & obj.Status & "#" & vbCrLf & "+" & obj.StatusText &
"+" & vbCrLf & "$" & obj.ResponseText & "$")
set obj = nothing
%>
I can change 'aCertificate' to 'blahblahblah', and get the message "A
certificate is required to complete client authentication", which I can
understand, as the WinHTTP component shouldn't find a certificate with this
subject.
We have tried changing authorisations as far as the eye can see, but have
got nowhere.
Please help! Deadline start of next week!
Cheers
Jon Little
Senior Developer
Verivox GmbH, Germany
Stephen Sulzer (Microsoft)
A likely cause of this problem is that the user account that your ASP
application runs under does not have permission to use the Local Machine
certificate. How did you install the certificate into the Local Machine
Root store?
You can use the WinHTTP Certificate Configuration tool (winhttpcertcfg.exe),
available in the WinHTTP 5.0 SDK, to grant permissions to use the
certificate to the ASP user account. This account is often the
IUSER_machinename or IWAM_machinename user account.
Please refer to the following documentation for more information:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/htt
p/winhttpcertcfg.asp
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jon Little" <jon_d_...@xxxhotmail.com> wrote in message
news:uqgrgRedCHA.2060@tkmsftngp09...
Stephen Sulzer (Microsoft)
Please use the winhttpcertcfg.exe tool to confirm that permissions on the
certificate are set appropriately. I would not use IE to import certificates
for anything other than the interactive user account. The MMC Certificates
snap-in can also be used to import certificates into the Local Machine
store, but it cannot grant access permissions to the IWAM or IUSR accounts.
To examine what user accounts have permission to use the "MyCertificate"
cert in the LOCAL_MACHINE\Root certificate store, for example, use the
following command:
winhttpcertcfg -l -c "LOCAL_MACHINE\Root" -s MyCertificate
To grant the IWAM_machinename user account access to the "MyCertificate"
cert, use the following command:
winhttpcertcfg -g -c "LOCAL_MACHINE\Root" -s MyCertificate -a
IWAM_machinename
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jon Little" <jon_d_...@xxxhotmail.com> wrote in message
news:e38ieADeCHA.1620@tkmsftngp08...
> Hi Stephen
>
> Thanks for your help. Unfortunately we've been through all the WinHTTP
> documentation, and the documentation for winhttpcertcfg as well.
>
> We install the certificate through IE6 (Tools -> Internet Options ->
> Content -> Certificates -> Import). We've tried every possible combination
> of option and certificate store, to no avail. We've also tried logging
> ourselves on with all possible users before installing the PC (including
> IWAM et al), again without success.
>
> Current line of attack is the trace output, configured with
winhttptracecfg.
> The output is attached to this posting.
>
> I can see from "WinHttpSetOption(0x2d00000, (47), 0x2770a3c [0x1], 20)"
> that the certificate is found OK and can be used (it WinHttpSetOption
> returns TRUE). WinHttpAddRequestHeaders then works fine, but things appear
> to go wrong on WinHttpSendRequest. The domain is resolved OK, but then I
get
> two errors: SEC_E_INTERNAL_ERROR and ERROR_WINHTTP_SECURE_FAILURE, leading
> WinHttpSendRequest to return FALSE.
>
> I suspect SEC_E_INTERNAL_ERROR and ERROR_WINHTTP_SECURE_FAILURE are trying
> to tell me something, but following links from
>
http://www.google.com/search?sourceid=navclient&q=SEC%5FE%5FINTERNAL%5FERROR
> and
>
http://www.google.com/search?sourceid=navclient&q=ERROR%5FWINHTTP%5FSECURE%5
> FFAILURE
> doesn't get me very far.
>
> Does the attached log help anyone?
>
> Regards from Germany
> Jon
>
>
>
Eddie Huibers
Are you running Windows 2000 or Windows NT 4?
We encounter the same error SEC_E_INTERNAL_ERROR when
trying to setup a SSL connection using WinHTTP in a ISAPI Extension DLL.
We are running Windows NT SP6A with IIS 4.
I posted this problem into platformsdk.internet.server.isapi-dev newsgroup
(message subject = Problem with SSLv3 from IIS4 ISAPI Extension DLL).
I got a reply from Brian [MS]:
>Hello
>I ran into the same problems on IIS 4 with WinHttp and setting a client
>cert. When I took my code to IIS 5.0 and did the same steps to install the
>cert using winhttpcertcfg.exe tool it all worked. I was never able to get
>WinHttp to send the client cert on NT 4.0. I did find a bug report on this
>and it does not look like they have fixed this on NT 4.0.
>You can repro the same issue using ASP or a VB DLL installed in MTS. It is
>not specific to ISAPI but a problem with WinHttp on NT 4.0.
>You can then do the same steps on Win2000 and it will work. So the bug is
>only on NT 4.0
>
>You may want to post this in the winHttp newsgroup to see if anyone there
>as found a way to make this work on NT 4.0
>http://msdn.microsoft.com/newsgroups/?url=/newsgroups/loadframes.asp?icp=ms
d
>n&slcid=us&newsgroup=microsoft.public.winhttp&frame=true
>
>Other then that you can try upgrading to Win2000 and IIS 5.0.
>
>Thanks
>Brian [MS]
>Microsoft Developer Support
>This posting is provided "AS IS" with no warranties, and confers no rights.
Our next step is to store the certificate and keys in a pfx file and read
the certificate
from file before setting up SSL. Maybe that works....
Thanks
Eddie
"Jon Little" <jon_d_...@xxxhotmail.com> wrote in message
> "Stephen Sulzer (Microsoft)" <ssu...@online.microsoft.com> wrote in
message
> news:OY6JSgwdCHA.1864@tkmsftngp11...
Jon Little
Thanks for this. We're in the process of trying the IIS 5.0 idea. I'll let
you know how we get on.
Regards from Heidelberg, Germany
Jon
"Eddie Huibers" <eddie_...@hotmail.com> wrote in message
news:uVJwnpGfCHA.1960@tkmsftngp12...
Jon Little
Just to update you on this - we have managed to make contact with the
server!
If appears that our mistake was to stick too closely to the WinHTTP
documentation. By changing the line
obj.SetClientCertificate "LOCAL_MACHINE\Root\aCertificate"
to
obj.SetClientCertificate "LOCAL_MACHINE\aCertificate"
(delete the \Root, \My, \Personal or whatever was the second element in the
'path'), the communication now works perfectly.
A big thank you to MS Support Germany for this one. Once we contacted them,
they were abel to reproduce the problem pretty much straight away and got
back to us with an answer within a few days.
Regards
Jon
"Jon Little" <jon_d_...@xxxhotmail.com> wrote in message
news:uqNnrHafCHA.2140@tkmsftngp10...
Stephen Sulzer (Microsoft)
However, it's interesting that omitting the store name solved the issue. If
the certificate string does not specify a store name, then WinHTTP defaults
to "MY". So "LOCAL_MACHINE\aCertificate" should be equivalent to
"LOCAL_MACHINE\MY\aCertificate". Did specifying "MY" for the store name not
work? (I don't believe certificate store names are case-sensitive.)
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jon Little" <jon_d_...@xxxhotmail.com> wrote in message
news:#pg5gYXhCHA.1104@tkmsftngp11...
Jon Little
I had assumed the same thing, and found it a bit odd when I saw the
solution. But it worked, so I was happy!
Cheers
Jon
"Stephen Sulzer (Microsoft)" <ssu...@online.microsoft.com> wrote in message
news:#i#d$orhCHA.1148@tkmsftngp11...