Blog Stats
  • Posts - 5
  • Articles - 0
  • Comments - 8
  • Trackbacks - 3

 

Wednesday, July 12, 2006

Using a password protected certificate with HTTPWebRequest

Yesterday I got the task to do a “quick” POC to test a call to a service (without SOAP) using a client certificate.  First of all please do not ask why we want to do it without SOAP.  That is a very loooong story.

After some initial poking around I found a few good links:

·        http://blogs.msdn.com/adarshk/archive/2004/09/01/224214.aspx

o       This is adarsh blog and I liked it because it is short and sweet and it put me on the right track.  Only ugly part is that this example was for .Net 2.0 beta so the X509CertificateEx class has been renamed to X509Certificate2.  It is still in the System.Security.Cryptography.X509Certificates namespace.

·        http://support.microsoft.com/kb/895971/en-us

o       This article is for .Net 1.0 and 1.1 but have some good tips if you want to see the installed certificates on your machine.

I ended up with a pretty clean solution but are having a weird problem when I run it on the server.  I get the following error sometimes and am trying to find a solution for this now (will keep you posted):

The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

I found some good info here:  http://weblogs.asp.net/jan/archive/2004/05/08/128394.aspx.  This is for WSE but it has fixed my problem as well.

Here is the current code I am playing with (and it works):

Some important using statements for this to work:

using System.IO;

using System.Net;

using System.Security.Cryptography.X509Certificates;

using System.Net.Security;

using System.Security.Policy;

private void SecureTest(){

try{

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(“http://myurl/TestService”);

req.Method = "POST";

req.KeepAlive = false;

X509Certificate2 Cert = new X509Certificate2();

string CertPath = “c:\temp\cert.p12”;

string CertPwd = “certpassword”;

Cert.Import(CertPath, CertPwd, X509KeyStorageFlags.PersistKeySet);

req.ClientCertificates.Add(Cert);

Stream s = req.GetRequestStream();

StreamWriter sw = new StreamWriter(s);

sw.Write(txtInput.Text);

sw.Close();

s.Close();

// submit synchronous HTTP request to Web server

WebResponse rsp = req.GetResponse();

// WebResponse provides stream-based access so let's go get it baby

StreamReader sr = new StreamReader(rsp.GetResponseStream());

txtSecureOutput.Text = sr.ReadToEnd();

}

catch (Exception ex) { throw ex; }

}

VB, C# and MTBC (my three brian cells)

I have been a VB guy since VB3.0.  IMHO it is the most productive language available.  I flunk out of typing school so typing is not for me.  VB has over the years made coding so easy without scarifying performance.  When .Net was released it was tough to not have some of the productivity features we were used to for years like “Edit and Continue” etc.  Most of that is now back again in VS 2005 and I am very happy.  If you are still using VB6 now is the time to switch to .Net.

 

I was also never big on the web applications.  It sure has a rightful place in our world.   I have done some web stuff and really like what is available in VS 2005 and ASP.Net 2.0.  I am also very excited about ATLAS.  It gives us a lot of features (based on the AJAX platform) that we used to either live without or had to code lines and lines of JavaScript to accomplish.  It is still in Beta but it is slick.

 

Recently I took a new job and my first few projects are C# and all are on ASP 2.0.  So as you can imagine I now have to do the wild thing and read documentation again.  My head hurts.  I only have three brain cells left and they are all preserve in some malted beverage for use (or abuse) by the next generation.  I have a hard time every morning to get the three of them going.

 

I am getting awfully familiar with C# now and although I do not mind using it I must say that I still prefer VB over C#.  It is just way more productive of a language and once it becomes IL it is all the same in any case.

 

 

Copyright © Ignus Bezuidenhout