[ejabberd] Re: SSL/TLS with ICA

Jaco Kroon jaco at kroon.co.za
Wed Dec 20 15:42:23 MSK 2006

> Jaco Kroon wrote:
>> Hi,
>> So permitting the only certificate in the file usherchain was the root
>> CA
>> file then the given s_client session in the previous post is correct.
>> The
>> patch looks good, except I'd recommend to also update the error message
>> just beneath the changed line to also reflect the function call change.
> Hi Jaco,
> 	For completeness I should have displayed that file. Yes it only has the
> root.

Just had to double check.

>> It should be noted that use_certificate_chain_file _REQUIRES_ that the
>> file be in PEM format (The way in which ejabberd was using it already
>> made
>> this assumption so this won't be a problem), it is also possible to
>> encode
>> the entire chain using DER format, however I'm not sure how one would go
>> about loading that into OpenSSL (I suspect one may need to use
>> use_certificate_file again - the DER encoding indicates whether a single
>> certificate is contained or whether there are multiple certificates).
> What struck me as odd was that in the Oreilly OpenSSL book it says that
> you must have the entire chain in the file you pass to
> use_certificate_chain_file. It must do something to validate the chain
> and then not send the root.

AFAIK OpenSSL doesn't actually do any verification of that chain, but I
have been wondering about it the last couple of days (even before digging
into this issue with ejabberd).  The RFC dictates that the certificates
should be in-order in the ServerHello, with the first first certificate
being the entity certificate, followed by it's issuer and so forth upto
either the 2nd or 1st level CA.  Thus I wonder whether OpenSSL does any
re-ordering required or not.

The reason for not requiring the 1st level CA is simply that the user
needs a copy of that cert in any case to decide whether it's trusted or
not, and it needs a full copy in order to verify that the public key does
indeed match the private key used to sign the self-signed CA cert.  It can
locate this certificate based on the issuer name in the 2nd-level

If OpenSSL does indeed perform some kind of verification it may well bomb
out then if only given a third or second level cert.  The chain is
_ALWAYS_ terminated at the root with a self-signed certificate.  So in
this case it would make sense that the full chain should be in the file. 
This would also allow OpenSSL to re-order the chain.

This should be trivial to test, unfortunately I don't have an
"experimental" jabber server.  So if someone with a set up experimental
box could please just take a 2nd/3rd level certificate without the full
chain and pass that to the new code it will either load the chain of one
certificate and present that, or it will bomb out.  Then try adding one
extra cert at a time, each time only adding the issuer of the previously
added certificate.  Then try with the chain re-ordered (need at least a
3rd level cert), as entity, root-ca, intermediate-ca.  I'm betting that
everything except the re-ordered chain will work (albeit the connection
will give errors on a 3rd-level only certificate).


More information about the ejabberd mailing list