jabberd port doesn't come with any certificates and is not allowing authorization?

[Matthew Seaman]

On 30/03/2012 08:57, Kaya Saman wrote:
>> You've got both 'register-enable' and 'register-oob' -- you probably
>> > don't want both of those, unless you do have an out-of-band method to
>> > create user accounts.

> Actually to allow IM clients to register will be better, though later
> on when I do a full implementation I will need to authenticate to
> either PAM or AD.

The point was that 'register-enable' turns on jabberd's internal account
creation functions, whereas 'register-oob' says to go to a separate site
in order to create the account.

If you're using a user database from elsewhere (pam or AD for instance),
then you'ld want neither of those options.

>> > Presumably you have created the required server x509 certificate.  If
>> > you're doing it on the cheap, that means a self-signed certificate.  In
>> > which case there simply won't be a cain of CA certs to worry about.  I'd
>> > also recommend require-starttls='true'
> I don't have an x509 cert, I discovered this though:
> 
> http://www.stanbarber.com/freebsd/creating-self-signed-ssl-certificates-on-freebsd-with-openssl
> 
> Is that what you mean or is the x509 different from the SSL self signed cert?

Hmmm... actually that article describes setting up your own
Certification Authority.  You certainly can do that if you want to --
but I'd recommend using security/tinyca rather than the fairly
rudimentary setup using little more than what comes with openssl
described above.

A self-signed certificate is actually a bit different to what the above
would get you.  They're both x509 certificates (where x509 means it just
adheres to a standard format published by the International
Telecomunications Union) -- a "certificate" in cryptography-speak is
simply a public key plus some other data describing how it is used,
which has been digitally signed to prevent tampering.  "self-signed"
means that the /private/ key used to sign the certificate is the
counterpart to the /public/ key contained in it.  You can tell from a
self-signed certificate that it hasn't been tampered with, but you have
no prima-facie way of telling who the certificate belongs to and whether
you should place any trust in it.  So this sort of certificate is
generally only useful for low value situations or within a small
organization where you already know the people behind whatever it is
that uses the certificate.

Now, all normal certificates are actually self-signed.  The difference
is that a cert you would buy from a recognised CA is also signed by the
CA's private key.  This is a way of saying that the certification
authority has gone through the due diligence of establishing that you
are in fact who you say you are and that by signing the certificate they
will vouch for you to third parties[*].  By setting up your own CA you
can reliably identify certificates you issued yourself.  That's all fine
and dandy, but probably over the top for a throwaway key used in
development and almost certainly not good enough for a service open to
the general public.

Anyhow, enough of this essay on public key cryptography.  To create a
self-signed certificate:

  1) Create a new public/private key pair.

  openssl genrsa -out foo.key 1024

     (note: this creates the key *without* a passphrase, which is what
      you usually want for services like jabber.  Since it has no
      passphrase, it is particularly vulnerable to being stolen, so
      take care to keep it safe.)

  2) Create a 'Certificate Signing Request' -- this is where you
     enter all the auxiliary data about what the key should be used for.

  openssl req -new -key foo.key -out foo.csr

     You'll be prompted for various identifying data.  Fill them in as
     far as you can be bothered -- the only really important one is the
     'Common Name' which should be the FQDN of your jabber server.  You
     don't need to fill in 'Email Address' -- that's really only
     necessary for a certificate used for authentication by a person.
     Nor do you need to bother with any 'Challenge Password' or
     optional company name -- those can be used by some CAs as part of
     their authentication procedures.

  3) Sign the public key  (part of the contents of the CSR) with its
     own private key to generate the certificate

  openssl x509 -req -days 365 -in foo.csr -signkey foo.key -out foo.crt

     Adjust '-days 365' to taste, as you'll need to repeat this signing
     step to renew the cert once that period of validity has passed.

  4) Specifically for jabberd2, concatenate the key and cert into one
     file:

  cat foo.key foo.crt > foo.pem

     This is an application specific thing: some apps like key and cert
     together like this, others use separate files for key and cert.

	Cheers,

	Matthew

[*] Which just begs the question of "who is this CA and why should I
trust them to vouch for anyone else?"  Well, there's a hierarchy of
certification authorities.  The CA can itself issue a certificate for
its certificate-signing key that is itself signed by some higher CA
saying that they are fit and proper people to take that role.  And so
on, ad nauseam.  Eventually you get to the top level, so called 'root'
CAs, which are presumed to be so well known by everyone that you can
just trust them without further quibble.  (Yeah, right.)

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120330/47857050/signature.pgp