access violation when calling WinHttpSetOption

[Laura Bagnall]

I am trying to use WinHttpSetOption to use a client certificate, and it's failing with an access violation.  Here's the code that is failing:

 

 //MY is the store the certificate is in.
 BOOL result = false;
 HCERTSTORE  hSystemStore;              // system store handle
 PCCERT_CONTEXT  pCertContext = NULL;   // Set to NULL for the first
                                       // call to
                                       // CertFindCertificateInStore.
 LPCWSTR lpszCertSubject = L"MyCertNameHere";

 

 

 

 hSystemStore = CertOpenSystemStore( 0, TEXT("MY") );
 if( hSystemStore )
 {
  pCertContext = CertFindCertificateInStore( hSystemStore,
   X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
   0,
   CERT_FIND_SUBJECT_STR,
   (LPVOID) lpszCertSubject,    //szCertName is subject string in the certificate.
   NULL );
  if( pCertContext )
  {
   WinHttpSetOption( hRequest, WINHTTP_OPTION_CLIENT_CERT_CONTEXT,
    (LPVOID) pCertContext, sizeof(CERT_CONTEXT) );
   CertFreeCertificateContext( pCertContext );
   result = true;
  }
  CertCloseStore( hSystemStore, 0 );
 }
 return result;

CertOpenSystemStore and CertFindCertificateInStore are succeeding just fine, but when I step through the line of code that says WinHttpSetOption, I see the following error in the Debug window.

 

First-chance exception in DLLHOST.EXE: 0xC0000005: Access Violation.

 

Prior to running the previous code, I've set up the hRequest handle with the following code:

 

    // Use WinHttpOpen to obtain a session handle.
    hSession = ::WinHttpOpen(  L"A WinHTTP Example Program/1.0",
  WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
  WINHTTP_NO_PROXY_NAME,
  WINHTTP_NO_PROXY_BYPASS, 0);
 if (!hSession)
  COMThrowComError( E_NETWORK_ERROR, IID_ICRMWorker,
  _T("::WinHttpOpen failed in CHTTPFileManager::OpenSession"));
 
    // Specify an HTTP server.
 hConnect = ::WinHttpConnect( hSession, pszServerName,
  INTERNET_DEFAULT_HTTP_PORT, 0);
 

 if (hConnect)
 {
  hRequest = ::WinHttpOpenRequest( hConnect, L"HEAD", AbsolutePathFromURL(lpPath),
   NULL, WINHTTP_NO_REFERER,
   WINHTTP_DEFAULT_ACCEPT_TYPES, 0);
 }

I'm running on Windows 2000 Pro, SP4, and the version of winhttp.dll in the system32 directory is 5.1.2600.1188.

 

HELP!  I have no clue how to debug this.

 

Thanks,

Laura

[Stephen Sulzer]

I don't know if this will help, but the call to WinHttpOpenRequest is
missing the WINHTTP_FLAG_SECURE flag. In order to use SSL or certificates,
WinHTTP requires that the application specify the SECURE flag. So your call
to WinHttpOpenRequest should look like this:

hRequest = ::WinHttpOpenRequest( hConnect, L"HEAD",
AbsolutePathFromURL(lpPath),
NULL, WINHTTP_NO_REFERER,
WINHTTP_DEFAULT_ACCEPT_TYPES,

WINHTTP_FLAG_SECURE);

Also, I would be careful with the WinHttpConnect call. If you are going to
send a request to an 'https:' URL, then you should probably specify either
INTERNET_DEFAULT_PORT or INTERNET_DEFAULT_HTTPS_PORT in the call to
WinHttpConnect. Specifying INTERNET_DEFAULT_HTTP_PORT will cause WinHTTP to
try to establish an SSL connection with port 80 of the target server, which
will likely fail.

If the crash still occurs, please obtain a callstack (at the point of the
first-chance exception in DLLHOST.EXE) and provide it. Even if the callstack
just contains non-symbolic addresses inside WINHTTP.DLL, it will help
Microsoft debug the problem further.

Regards,
Stephen

[Laura Bagnall]

Thanks. I put in the flag WINHTTP_FLAG_SECURE and specified
INTERNET_DEFAULT_HTTPS_PORT and the crash goes away. However, this gets me
to my next question. Is it possible to use client certificates for
authentication and not for encryption?

Here's my scenario. I am trying to programmatically copy large files onto a
server using the WebDAV protocol. The verbs that I am using are "HEAD" (to
find out if the file is there already), "MOVE","DELETE","MKCOL" and "PUT".
I want to use an authentication scheme to make sure that only authorized
users have access to that directory, but I don't want the files themselves
encrypted enroute, because they are very large (they are video files), and
the contents aren't sensitive information. The other variable is that I am
deploying the server into an environment that is not guaranteed to be
running a domain server (it could be installed into a workgroup
environment). Anonymous authentication is out, and Basic isn't much better,
because the userid and password are transmitted in clear text. Integrated
Windows and Digest authentication both depend on a domain server. That
leaves certificates. What I am attempting to do is to set up the ACL on the
folder in question to allow permissions to a specific account that is local
to the server, and use the client certificate mapping feature in IIS to map
the certificate to that account. However, I didn't realize that you
couldn't use certificates unless you also use SSL, and it is an unacceptable
performance hit to encrypt the contents of the files as they are being
copied. I also know the hack where if you create two local accounts on two
different machines that have the same name and password, you can use them to
do authentication between those two machines, but for various reasons that
solution is out as well.

Any suggestions?

Laura

"Stephen Sulzer" <sasulzer_at_seanet.com> wrote in message
news:vj891ib...@corp.supernews.com...

[Stephen Sulzer]

I would recommend asking this question on the
microsoft.public.inetserver.iis.security newsgroup.

I think it is possible to configure IIS to require client certificates
without enabling SSL encryption, but I am not positive.

The following article from Microsoft discusses how to configure IIS to map
certificates to user accounts like you are doing:

"Step-by-Step Guide to Mapping Certificates to User Accounts"
http://www.microsoft.com/windows2000/techinfo/planning/security/mappingcerts.asp

Looking at Step 16, (configuring the security properties for a web server
directory), it appears you can select "accept client certificates" without
checking "require secure channel (SSL)". It also talks about Active
Directory; I don't know if using Active Directory is required to do the
certificate-to-account mapping, you might want to also ask about that on the
inetserver.iis.security newsgroup.

Regards,
Stephen

"Laura Bagnall" <lbag...@pinnaclesys.com> wrote in message
news:e9Mo5sgX...@TK2MSFTNGP09.phx.gbl...