[Mono-dev] mod_mono and SSL

Ivaylo Baylov ivo at datamax.bg
Mon May 15 07:18:40 EDT 2006

Hi, Sebastien!

The workaround with server variables may be useful when nothing else is
left, but it is error prone, since:

1. The CERT_COOKIE IIS variable meaning is not documented; I've used a
SHA-1 digest on the DER encoded certificate;
2. Apache mod_ssl string representation of issuer and subject DNs
deviates from the canonical LDIF form (actually, the openssl is to blame
for that).

As a result, you can not simply replace the IIS with mod-mono and expect
the things to work as before.

So, since there is no official plan concerning ssl features of
mod-mono-server, I'll dig a bit further to make things more IIS-like,
and send them to you, if you don't mind :-)


I've made also a minor fixup to make mod-mono-server work on remote
host; there were some networking issues in there.

Ivaylo Baylov

On Mon, 2006-05-15 at 02:50, Sebastien Pouliot wrote: 
> Hello Ivaylo,
> On Sun, 2006-05-14 at 22:44 +0300, Ivaylo Baylov wrote:
> > In my porting efforts of an application that utilizes SSL certificates
> > I've stuck on the HttpClientCertificate hollow implementation in
> > mod-mono-server.
> IIRC the HttpClientCertificate class itself is pretty much complete.
> However it works if supplied with the basic information from the web
> server. This was done for XSP a while back and most of it *can* be
> shared with mod_mono.
> > Thus I've tuned the mod-mono-server a bit to make it export server
> > variables related to ssl session certificates and, accordingly, the
> > application to use CERT_ server variables instead of
> > HttpClientCertificate instances.
> If the variables are exported (i.e. available to mod_mono) then it
> should be really simple to "feed them" to HttpClientCertificate. You may
> already have 99% if the solution in your hands (and I'd be happy to help
> you complete it).
> > Are there any official plans to work in this direction and/or implement
> > the HttpClientCertificate for mod_mono?
> There's rarely an official plan for such specific features (it's more on
> a need-by-need basis) so it mostly comes from features/bug request or
> from contributors patches (both comes with the big advantages of having
> someone interested enough to test it in a real environment :-).

More information about the Mono-devel-list mailing list