Bob on Development

January 16, 2007

Accepting a Flaky Certificate When Doing an SSL POST

Filed under: C# — Bob Grommes @ 12:56 pm

I needed to communicate with a web server that requires an SSL connection yet does not have a valid SSL cert. This is actually not that uncommon when dealing with various business partners. In this case it’s a large multinational corporation with a web farm. The certificate is issued to but what actually answers is something like Even giant, soulless corporations don’t want to buy an SSL certificate for every box in their web farm!

My client’s legacy ASP application used an ActiveX component and to accept such certificates you simply set a property to true — something like AcceptAllSSLCerts. It was that simple! In porting this to .NET, though, it’s one of those things that gets more involved, because this is an area where the .NET class libraries are a bit on the thin, low-level side. There no doubt are third party products that simplify this, but following is a piece of code that did the trick for me:

First, create the following class:

internal class AcceptAllCertificatePolicy : System.Net.ICertificatePolicy {

  public AcceptAllCertificatePolicy() {}

  public bool CheckValidationResult(System.Net.ServicePoint sp,
                                    System.Security.Cryptography.X509Certificates.X509Certificate cert,
                                    System.Net.WebRequest req,
                                    int certProb) {
    return true;


Now, execute the following call just before doing the POST:

System.Net.ServicePointManager.CertificatePolicy = new AcceptAllCertificatePolicy();

This works fine in both .NET 1.1 and 2.0. In 2.0 you’ll get a warning that this call is deprecated and replaced with some kid of callback; in the rush of deadlines I have not bothered to track that down. Another thing I did not need to check was whether setting the ServicePointManager.CertificatePolicy property is global for your entire app (I’m pretty sure it is) and whether it needs to be called before every POST (I’m pretty sure not). However in my case it doesn’t matter because it’s a non performance-critical routine that usually is only called once per program run anyway. Of course if I had other SSL connections to make where I didn’t want to relax this requirement I’d need to figure out how to toggle this on and off.

This actually makes a nice real-world example of how to make decisions about allocating your precious time. Many of us forget that the customer is paying us to solve a problem, not to solve it elegantly. There is a line you don’t want to cross, of course, where you write slovenly code that will come back to haunt you someday. But in this case, if I’d spent an extra 20 minutes making sure I was using the latest API call and tweaking for efficiency that would be unlikely to ever be noticed, then I’m not serving the customer’s best interests. What serves their interests is to make sure it works right.

I will confess that this has gone on my List of Interesting Things To Check Out Someday in my Spare Time (Ha-ha). No problem fine-tuning your code on your own time … it’s just not always warranted on the customer’s time.

December 27, 2006

Proper Casing a String in .NET

Filed under: C#,Techniques — Bob Grommes @ 2:22 pm

Rick Strahl saved me a minor headache today by pointing out a somewhat hidden and arguably misplaced method in the BCL for proper casing strings. Combining that with a small fix provided by one of his respondents (the method doesn’t work if the input string is all upper cased), you get:

private string ProperCase(string s) {
  return System.Threading.Thread.CurrentThread.CurrentCulture.TextInfo.ToTitleCase(s.ToLower());

As he aptly points out, it’s all there somewhere in the dogpile, if only you can find it.

Create a free website or blog at