Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Certificates, WSE 2.0, nothing works!
Message
 
 
To
All
General information
Forum:
ASP.NET
Category:
Other
Title:
Certificates, WSE 2.0, nothing works!
Miscellaneous
Thread ID:
01187173
Message ID:
01187173
Views:
69
Hey all,

I have been struggling forever on this.

All I want to do is make a new server, called INTRANET1, act the same as existing server INTRANET. The main thing INTRANET1 needs is to run credit bureau reports via TransUnion (TU). INTRANET works flawlessly in this regard. People send requests to INTRANET, and an ASPX page on INTRANET chooses the right locally-stored certificate (.cer), makes web request to TU, and returns the responded HTML. This all runs through an ASP username called "CustomASPNET".

On INTRANET1 (the new server), I have set up CustomASPNET, and given it access to everything. Logged directly into that username, I installed the TransUnion certificate, and was successful. In fact, I can use IE directly and access the TU site, it prompts for cert, I select the cert, and I get the expected page back. So the certificate is 100% valid, from that machine, from that username.

But when I try to select the certificate in code, using a .cer file thusly:
Dim TUcert As X509Certificate = X509Certificate.CreateFromCertFile(mcCertFile)
.
.
oRequest.ClientCertificates.Add(TUCert)
.
.
oRequest.GetResponse()
I end up having the oRequest.GetResponse() line error out, and the error in the caught exception is "403 - Forbidden". In the error handler, I also print out the username and everything else I can think of to troubleshoot this. The username being used in the aspx page is "CustomASPNET", as expected, so I have the impersonation and security all set up correctly as far as I can tell.

I have now seen the Web Services 2.0/3.0 way of doing certs, accessing the local certificate store for the current user. In fact, I whipped up a C# .NET app to display all certs in the local (CustomASPNET) store, and that executable runs fine on INTRANET1. It has all the certificates there I would expect (the root authority cert as well as the Personal-store cert that the .cer file was generated from).

No matter what I do, I can't get Web Services namespaces to work on my aspx page. I place the line:
< %@ import Namespace="Microsoft.Web.Services2" % >
at the top of the page with the rest of the imports, and it errors out, saying "Namespace or type 'Services2' for the Imports 'Microsoft.Web.Services2' cannot be found." So, I can't even get WSE to be available for my web page, must less use the X509CertificateStore object to try the cert that way! I checked the assembly cache, and Microsoft.Web.Services2 is there, along with all the other namespaces that DO work fine on the ASPX page. I have stopped, reset, started IIS several times too -- all to no avail.

Over this past week, I have spent a solid 20-25 hours on this, getting nowhere, and not even getting a foothold on how to DEBUG this stupid thing. There is no way to tell why my access is being forbidden, and interactively I can gain access perfectly. When I couldn't even get WSE to be available to my ASP.Net page, that was the last straw, time to head for the UT...

Please, please, please help me here. We can't switch to this new server without having credit reports working. By the way, one other difference between INTRANET and INTRANET1 is that INTRANET is Win2000 while INTRANET1 is Win2003, but I can't see why that would matter; especially since, as I said, the certificate works fine when I select it in IE manually.

Also, I want to point out that I am already using a custom-coded class on my aspx page that speaks the ICertificatePolicy language and always does a "return true" to make sure all certificates are considered valid. The way I understand it (I did not originally build all of this), that is what allows the server to select the right .cer without a user needing to sit there and click through the certificate dialog. So, I have that part in there too, and again, all of it works 100% flawlessly on INTRANET.

Thanks for any help anyone can offer. Sorry this got so long, probably a sign of my frustration and the fact that I have completely spent myself on this...

Thanks,
JoeK
Next
Reply
Map
View

Click here to load this message in the networking platform