Friday, February 24, 2006

 

Asp.Net project hell

Yet again I have lost several hours due to Asp.Nets definately flacky web projects in VS.Net 2003.
This has happened to me several times. Sometimes I can fix it but I am never quite sure what does it in the end. This time I had to resort to using a different web project name.

Basically, I was adding a new web project and every time added it, it would add it but then say "project unavailable". If I closed the solution and opened it would then say "can't find file" or some such message. I deleted every trace of the project from my computer, including in IIS and all related files. I then tried again, and still got the same error.
I then tried a project with a different name. this worked fine...go figure
I didn't really want a different name though so I tried (in vain) to get it to work with the original name. I checked everything from webinfo file, to project files, to source safe working folders. Nothing worked.

So in the end I now have a project with a name which isn't quite what I wanted...

I haven't used VS.NET 2005 yet, but I really hope this problem is resolved...

Monday, February 13, 2006

 

Validating Sql Server objects

I recently wrote a handy little tool that goes through every stored procedure, view and function in a database and tests to see if they compile. I find this really useful if I am going through a process of restructuring the database, as well as to give me some confidence before we deploy that everything compiles.
I have posted the source onto Code Project.

Amendment:
Just to clarify slightly, this tool will only pick up stored procs etc that fail to compile. Just because something compiles does not mean it will work. One example would be if a table in a stored proc did not exist. This would compile ok, as Sql Server will use late-binding in this case. However, when you run it, then it will error.

Wednesday, February 01, 2006

 

Web services and client certificates

I recently had a requirement to use a client certificate with an SSL web service call to enhance the security on an existing web service. My preferred option was to use WS-Security but that was not possible due to constraints at the server. So the only option was to use a client certificate.
Sounded fairly straightforward.
I read this article which seemed easy enough...so when I came to try it. It just would not work.
The client certificate would not appear at the server. If I made the server require a client cert I got a 403 Forbidden error on my web service call.
I googled it and found a blog entry by Kevin Hammond which made me hopeful. Unfortunately, it still did not work.
So after wasting a couple of hours tweaking a few things, search google etc I didn't get anywhere.
I then decided to see if I could access the web service via interet explorer with a client certificate. This didn't work either...I kept getting the error "HTTP 403.13 - Forbidden: Client certificate revoked".
I was stumped for a while until I noticed the following properties of the certificate itself (view through the certifcate store MMC addin)
CRL Distribution Points
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://myserver/CertEnroll/myserver.crl
URL=file://\\myserver\CertEnroll\myserver.crl

Authority Information Access
[1]Authority Info Access
Access Method=Certification Authority Issuer (3.7.1.1.4.5.7.7.8.1)
Alternative Name:
URL=http://myserver/CertEnroll/myserver_myserver.crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (3.7.1.1.4.5.7.7.8.1)
Alternative Name:
URL=file://\\myserver\CertEnroll\myserver_myserver.crt

I was using my own certificate authority for this development work, and had installed certificate server on my dev server. I realised that this same server has sharepoint installed on it, and that when sharepoint was installed it took over port 80 and created a new website on port 81. The certificate server bits and pieces had all been set up on port 81. So I copied the settings for CertSrv, CertEnroll and CertControl to the sharepoint site on port 80 and told sharepoint to exclude these folders from itself.
I then re-issued my client certificate, and it worked. With IE I could now access my web service.
I then went back to the code which calls the web service, plugged in the new certificate and it also worked. Hurrah. I was very relieved.
This new certificate was installed in my Current User - Personal store. I really wanted it in the Local Machine store. So I installed it there, tweaked my code to look there instead and ... d'oh...it didn't work.
I tried several things like re-installing the CA in the Local Machine trusted root. I also tried the winhttpcertcfg tool. All to no avail.

So at that point I, erm, gave up. I could live with the client cert having to be in the Current User store (it would mean a bit of extra buggering about to deploy - but at least it works). There was no more time to solve the Local Machine store problem. If anyone has any ideas on that one I would be interested to here it.

Anyway, I think the lesson here is:
Certificate Server has to be installed on port 80 (either that or I missed some option to tell it what port it was installed on)

This page is powered by Blogger. Isn't yours?