mosquitto-users team mailing list archive

["Brian Reinhold" <brianreinhold@xxxxxxxxxxxxxxxxxxx>]

Thanks Roger,

That does help. It whittles down the possibilities.

So if I have a private key for the server (now in a keystore in jks format encrypted by a password) and a self signed X509 certificate from the client in my truststore (also in a truststore in jks format encrypted with a password), how would I set this up for mosquito? I can export the private key from the keystore in PEM format and I can do the same for the public certificate in the truststore. The two files are sufficient for mutually authenticated TLS. Somehow I get the impression that I need a third certificate minimum to work with Mosquitto, for example the public certificate matching the server's private key. (All my 'public' certificates at this time are self-signed).

If I have these two files now in PEM format, how would I configure Mosquitto to use them?
Can they be in the same directory?
Do I have to generate a public certificate from the server's private key (I can easily generate a self-signed certificate)?
Can all public certificates be self-signed?

Thanks,

Brian

-----Original Message-----
From: rogerlight@xxxxxxxxx [mailto:rogerlight@xxxxxxxxx] On Behalf Of Roger Light
Sent: Monday, December 02, 2013 5:20 PM
To: Brian Reinhold
Cc: mosquitto-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Mosquitto-users] Understanding how the mosquitto server uses SSL

Hi Brian,

My understanding is that truststore and keystore are primarily terms that are used in Java based TLS implementations. I don't think they occur at all in the openssl documentation, which is what mosquitto uses for its TLS support.

certfile contains the server certificate. It can also contain the Certificate Authority certificate that signed the server certificate and any other certificates to complete the chain to the root CA. If it does, the certificates must be sorted starting with the server certificate and then the CA certificates in order. They must be in PEM format. It could also be a self signed certificate (but as it is easy to generate your own certificates with yourself as CA for testing I don't see the need myself)


keyfile contains the server private key. It must be in PEM format. If it is encrypted, the broker will ask for a password on startup.

keyfile is the rough equivalent of the keystore, but there is no possibility of generating certificates internally to the broker. To be honest, I don't see that as a useful feature.

cafile and capath are the rough equivalents of the truststore. The difference is that rather than maintaining a list of trusted clients, the intent is that the files contain trusted CA certificates. When a client attempts to authenticate the broker checks to see if the client certificate was signed by a trusted CA certficate. The broker also has a list of revoked client certificates. The difference between cafile and capath is that cafile is a single file containing all of the trusted CAs in PEM format. capath is a directory containing individual CA certificate files, again in PEM format. The files must have .pem or .crt endings and must have links generated using the c_rehash utility.
Most Linux distributions maintain a directory of CA certificates in /etc/ssl/certs/ for use with web browsers.

I've tended to keep the server certificate separate from CA certificates, so certfile only contained the server certificate and the trusted CA certificates, which also signed the server certificates, were in cafile/capath.

You actually have to provide one of capath/cafile even if client authentication isn't being used, this shouldn't be necessary.

I hope that clarifies things a bit.

Cheers,

Roger


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3629/6886 - Release Date: 12/02/13

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3629/6886 - Release Date: 12/02/13