CAPICOM Signer.Load returns -2147024894 (80070002)

[Carl Colijn]

Hi,

I am trying to digitally sign an executable on my (hosted) web server.
For this I use the below ASP VBScript:

Dim oCrypto
Set oCrypto = CreateObject("CAPICOM.SignedCode")
Dim oSigner
Set oSigner = CreateObject("CAPICOM.Signer")
Call oSigner.Load(Server.MapPath("/cgi-bin/MyKey.pfx"), sPassword)
oCrypto.FileName = Server.MapPath("/cgi-bin/try.exe")
Call oCrypto.Sign(oSigner)
Call oCrypto.TimeStamp("http://timestamp.comodoca.com/authenticode")

Signer.Load however keeps failing with error code -2147024894
(80070002), no matter what I try. This script runs fine on my dev
machine (XP Pro SP3, CAPICOM 2.1.0.2, IIS 5.1), signing and
timestamping "try.exe", but when I upload the script to my web site and
run it there I get the mentioned error. In the end this code needs to
run as a C++ CGI exe (using COM), but there it fails at the same
location (Signer.Load) with the same error (the ASP script was in fact
just a check if I at least could get it to work that way).

MSDN on Signer.Load does tell us "This method raises
CAPICOM_E_NOT_ALLOWED when it is scripted from a Web-based
application", but CAPICOM_E_NOT_ALLOWED is another error code than the
one I'm getting (and besides: it works on my local dev machine).

The things I have tried so far:
- Check with the Windows api (C++) and with FileSystemObject (VBS) if
the key file exists => it does
- Check with the Windows api (C++) that I have read permission on the
file => I do
- Check if the file/path is correct string-wise (C++; terminating NULL
etc.) => it is
- Put the .pfx to use and the .exe to sign in another folder besides
/cgi-bin (VBS) => no difference

If anyone has any idea what might be going on here, I would be very
thankfull! An alternative approach for signing exe's on the server is
also appreciated, but I do not have the access rights to install
certificates in a personal store on my shared web hoster's server
(hence the .pfx file route I'm trying now).

[Carl Colijn]

Post by Carl Colijn
Dim oCrypto
Set oCrypto = CreateObject("CAPICOM.SignedCode")
Dim oSigner
Set oSigner = CreateObject("CAPICOM.Signer")
Call oSigner.Load(Server.MapPath("/cgi-bin/MyKey.pfx"), sPassword)
oCrypto.FileName = Server.MapPath("/cgi-bin/try.exe")
Call oCrypto.Sign(oSigner)
Call oCrypto.TimeStamp("http://timestamp.comodoca.com/authenticode")

The CAPICOM's Signer.Load method returned -2147024894 / 80070002; the
accompanying error description for this error code is "The system
cannot find the file specified". When I look for the file with
FileSystemObject, it reports it is there and I can even read from it
using the OpenTextFile method. So the file is accessible. I have now
tried to sign a test executable in three ways;
1) ASP page using the above VBScript;
2) C++ CGI exe using the same CAPICOM objects as in the script above;
3) C++ CGI exe calling SignTool with the correct command line parameters
All methods return the same error (SignTool in /v[erbose] mode gives a
textual error message in the line of "The system cannot find the file
specified" as well).

Then I changed the aboce script to use an invalid password - now the
error being raised changes to -2147024810 = "The specified network
password is not correct"! How does CAPICOM know the password is
incorrect if it can't find the file? Handing over an invalid filepath
for the pfx file (and keeping the pass invalid as well) brings back the
"The system cannot find the file specified" error. It thus seems the
"The system cannot find the file specified" is also raised in other
circumstances that the file actually not being found.

I suppose the code path involved by CAPICOM also uses the CryptoAPI
call "PFXImportCertStore" to load my .pfx file into a temporary store
and continues from there. Could it be that there are
security/access-related issues at hand here; the web server's user
account (and thus any CGI exe's spawned by it as well) having
restricted access to the key stores involved? The web server at my web
hosting provider undoubtfully has the security tightened down more than
my local development machine, on which the code manages to run
successfully...

Any ideas?