[Mono-list] SSL/TLS client to an Erlang server

[Essien Essien]

Hi guys,

Didn't come back to this sooner untill I satisfied myself that I had dug deeper.

On Mon, Apr 27, 2009 at 1:25 PM, Sebastien Pouliot
<sebastien.pouliot at gmail.com> wrote:
> On Sun, 2009-04-26 at 08:50 +0100, Essien Essien wrote:
>> Hi,
>>
>>
>> I'm testing with self-signed certificates, created with openssl, and
>> I've been able to figure out how to convert PEM certs to DER format
>> which .NET/Mono seems to require.
>
> why don't you use mono-provided tools to create your self-signed
> certificate ?

Actually, the server is not Mono based, only the client is... and I
like to think that the openssl toolkit should just work with
everyother thing, since its more or less defacto. (?)
>
> googling for "mono self signed certificate" returns a bunch of helpful
> hits, including:
> http://mono-project.com/UsingClientCertificatesWithXSP
> http://pages.infinit.net/ctech/20041129-0607.html

I finally found the problem in the one authoritative place - the sources :)

The problem is that by default, when generating self-signed
certificates with openssl, KeyUsage and ExtendedKeyUsage extensions
are not included. Most other CA processing software seem to accept
these as well, but Mono refuses to use a Certificate for server
validation if it does not include at least One of these extensions or
the older Netscape extensions. Also, once included, the KeyUsage
extension Key Encipherment bit must be set.

Now, It would appear that rfc5280 is pretty verbose, but not too clear
on some things. On KeyUsage extension, the RFC has this to say:

" Conforming CAs MUST include this extension in certificates that
   contain public keys that are used to validate digital signatures on
   _other_ public key certificates or CRLs.  When present, conforming CAs
   SHOULD mark this extension as critical."

The problem is that self-signed certificates seem to slip through a
hole in this system. It demands that certs that contain keys used to
validate OTHER certs MUST include this extension, but self-signed
certs are used to validate THEMSELVES not OTHERS (semantics? dunno),
but openssl and a lot of other CA processing system seem to interpret
this similarly, except Mono.

I don't know if I should call this a bug to be fixed or a feature
request to be added, just so that it allows Mono to easily
interoperate "out-of-the-box(tm)" with other systems (ok... at least
with openssl) :)

Version of Mono in question: mono-2.4.2
File: mcs/class/Mono.Security/Mono.Security.Protocol.Tls.Handshake.Client/TlsServerCertificate.cs
method: checkCertificateUsage(X509Certificate)


>> I've also been able to figure out that I need to usethe certmgr
>> command line tool to manager certs in the mono cert stores.
>>
>> My problem right now is that so far, my self-signed certs created with
>> openssl then converted and imported into mono certificate stores
>> "Trust" and "CA" do not work against my erlang server.
>>
>> My commands which I use are below:
>>
>> To create the cert:
>>
>> $ openssl genrsa -out key.pem 1024
>> $ openssl req -new -x509 -key key.pem -sha1 -nodes -out cert.pem
>>
>> To convert to DER cert for use in Mono
>>
>> $ openssl x509 -in cert.pem -outform DER -out cert.cer
>>
>> To import into mono's "Trust" store
>>
>> $ certmgr -add -c Trust cert.cer
>

For the record. These steps work, incase someone else needs to use
Openssl generated certs with Mono. The only problem is the default
openssl config.

The key is to update the [v3_req] and [v3_ca] sections of openssl.cnf
and ensure keyUsage is NOT commented out and it contains the
keyEncipherment setting. Also, in [v3_ca] section, enabled the
"critical" option in the basicContraints setting.

Hopefully, that helps someone else.

> Try to split out your problem, like
>
> * can you use any other tool (like openssl) to connect to your server ?

Yes.

>
> * if so what does it log (e.g. debug mode if any with your tool) ?

Openssl comes with a test client and server which allows you to check
the protocol stages as it progreses. But see above, for actual
problem.

>
> * have you tried wireshark to see what's happening at the protocol
> level ?

Yes. See above.
>
>>

cheers,
Essien