Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Clone
HTTPS:
git clone https://vervis.peers.community/repos/yEzqv
SSH:
git clone USERNAME@vervis.peers.community:yEzqv
Branches
Tags
Publishing_to_Clients.mdwn
In order to be able to authenticate your server and establish a secure connection, clients will need to get your CA certificate and install it on their computer. You can probably put it on your SSL policy page, or link to it. Once a client downloads it, she will generally need to do two things: Verify it is really yours, and install it somewhere where the client software can see.
Many user applications have their own certificate collections, in which case the user will need to manually add it to each such application. But more integrated applications use a system-global or a per-user certificate collection, and these make life easier because you only install the certificate once. Then all programs using the global collection will automatically recognize your CA.
Preferrably, you’ll give the users a way to verify the certificate. Otherwise, a fake website could give them a fake certificate. There are several ways to do this, but I’m not an expert so I’ll suggest a single simple straight-forward one: Sign the certificate using your own PGP key, and publish the signature online.
You can either use GnuPG directly on the commandline, or install a GUI called GNU Privacy Assistant. Personally I didn’t like its UI very much, but maybe I just need time to get used to it. Anyway, you can try it for yourself:
apt-get install gpa
You can see the client’s side of the story to help you. There is a user guide written in parallel to this one, explaining how to use the certificates of an independent CA. There is also a user guide specific to Partager, which you can use as a template.
[[TODO|TODO/OPEN]] link to them
[[TODO|TODO/OPEN]] mention any monkeysphere stuff if relevant
You can sign the certificate like this:
gpg --detach-sign example-ca.crt
You will get a binary file example-ca.crt.sig
which you can publish, and guide users how to verify it. The idea is to download the certificate and the signature, and if the verification succeeds the client installs the certificate (and can delete the signature she downloaded). A verification can be done like this:
gpg --verify example-ca.crt.sig example-ca.crt
If you do this, you’ll probably see something like this because you trust your own key:
gpg: Signature made IDT 09:29:10 2014 Jul 14 Mon using RSA key ID 937A67EF
gpg: Good signature from "John Doe <jdoe@riseup.net>"
gpg: aka "[jpeg image of size 4232]"
A client which doesn’t trust your key will see an additional warning like this:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
In order to verify the key is the right one, guide the users to compare the key fingerprint to the one you supply. The key ID from the gpg --verify
output can be used:
gpg --fingerprint 937A67EF
The fingerprint will appear in the output, e.g.
Key fingerprint = 6175 5EC3 A2BC 3932 1BE2 85F5 846A DBA3 937A 67EF
In a small community, it can easily be arranged for all users to sign the PGP key of the system administrator, and then there’s no need to check the fingerprint because gpg
determines they key is trusted. It is probably the most secure way for any other case as well, i.e. have the key signed on an unrelated occasion, e.g. in a key signing party, or in a planned face-to-face meeting.
Last thing, I’m not an expert. If you want to know more and understand these topics better, you should find text written by people with more knowledge. If you are one of them, and you see mistakes or inaccuracies here, please tell me so that I can fix them.