[Mono-list] self signed certificate

[Edward Ned Harvey (mono)]

> From: Jonathan Pryor [mailto:jonpryor at vt.edu]
> 
> On Oct 24, 2013, at 6:02 PM, Edward Ned Harvey (mono)
> <edward.harvey.mono at clevertrove.com> wrote:
> > All the guides out there that I can find tell people to use "makecert," which
> isn't an option.  Or use openssl.
> 
> Why aren't those options? It shouldn't matter how you create the cert, as
> long as you have one...

Makecert might be good enough for testing and development, but it's not crypto strong, and also generally not available on whatever system the IT person (customer) is deploying their initial configuration.

Openssl is crypto strong, but also not always available on the target system.  I think the thing I'm settling on is Windows users can use the integrated cert generator in my application, which uses the Cert Enroll COM library.  And for linux/unix users, we'll include instructions to do it with openssl.


> ...except that the normal System.Net stack wants a "valid" certificate chain
> lest it start throwing exceptions, and it'll start throwing exceptions with your
> self-signed cert.
> 
> The workaround for this is to set the
> System.Net.ServicePointManager.ServerCertificateValidationCallback
> property [0, 1] to a delegate which will check that the certificate you're
> getting from the server matches what your app expects. If it does, it can
> return `true` and the certificate will be used anyway, allowing you to use a
> self-signed cert. If the delegate returns `false`, the connection will be
> refused, as normal.

That might be exactly the problem I'm trying to solve, thanks for the suggestion - and I'll look more closely at the reference examples to see if they just omitted that detail, or what...

One thing worth mention, is that at one point, I generated the self-signed cert (including root CA) and I imported the root CA into the client root CA's.  And I still got the exception.

So anyway, I'll dig into it some more.  Thanks for the suggestions.