NOTE: Federation is disabled on this instance!You can test federation between the following instances:
Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
The instructions below are written for the Rel4tion server. For more general purpose instructions for CAs, see [[SSL]].
Rel4tion manages its own SSL certificates. Since they aren’t signed by a centralized [[!wikipedia “Certificate Authority”]] (CA), your client applications (web browser, Jabber client, etc.) won’t trust them unless you explicity mark them as trusted. Many applications will simply ask you whether you wish to trust the certificate. This is probably the safest approach.
In addition to this, Rel4tion manages its own CA. Trusting the CA means your computer automatically trusts any certificate signed by it. However, since this CA is made by [[fr33domlover]], who just runs a small home server and isn’t a security expert, you should understand the implications before you install it. If you don’t much about SSL and CAs, you probably shouldn’t do that. Just follow to the next section below.
This is the best path for using Rel4tion’s server with SSL/TLS. Here are the options:
If you took the first path in the previous section (trusting specific certificates), please ignore this section.
If you understand the implications, this is an option too. Anyway, read [[here|http://www.inventati.org/en/ssl.html]] before you start. Specifically, this quote from that page is important:
As we said before, you put your trust in the hands of the CA when accepting that the connection to a site is secure. We decided it would be illogical to put the trust relationship between our users and us in the hands of profit-oriented corporations. Corporations that are also keen to collaborate with governments and intelligence agencies. For example, your government could get a commercial CA to collaborate, and hand over a signed certificate for our domains. Then the government will be able to set up a proxy between you and us, letting your browser believe that the connection is secure, while being able to decypher and intercept all your traffic. As recent news have proved, we made the right decision not to trust corporations to stand up to government wiretapping requests.
So why does Rel4tion have a CA?
WARNING: If your computer trusts Rel4tion’s CA, it means that the people who have access to the CA’s private key ([[fr33domlover]], unless someone manages to make a copy of it) can authorize any certificate they like, and your computer will automatically trust them. This is true for any CA, but some CAs are approved by GNU/Linux distributions and web browsers, while Rel4tion’s CA hasn’t been tested by any “authority”. So make sure you understand the risk before proceeding.
The following instructions are for the Debian-based distributions. Information about other (fully free) distributions, such as Parabola, is welcome.
If you still want to install the CA, here’s how.
Get the CA certificate and the signature from the website. You ca do it on the command like like this:
$ wget --no-verbose http://rel4tion.org/rel4tion-ca.crt 2014-07-14 10:07:13 URL:http://rel4tion.org/rel4tion-ca.crt [2667/2667] -> "rel4tion-ca.crt"  $ wget --no-verbose http://rel4tion.org/rel4tion-ca.crt.sig 2014-07-14 10:07:13 URL:http://rel4tion.org/rel4tion-ca.crt.sig [287/287] -> "rel4tion-ca.crt.sig" 
If you happen to trust [[fr33domlover]]’s GPG key, you just need to verify the signature. GnuPG will inform you it is trusted (unless it isn’t):
$ gpg --verify rel4tion-ca.crt.sig rel4tion-ca.crt gpg: Signature made IST 20:54:50 2014 Nov 26 Wed using RSA key ID 63E5E57D gpg: Good signature from "fr33domlover <email@example.com>" gpg: aka "fr33domlover <firstname.lastname@example.org>" gpg: aka "fr33domlover <email@example.com>"
Notice the Good signature line. That is what tells you whether you GPG-trust the key.
If you don’t GPG-trust the key, make sure it’s the right key by comparing its fingerprint. You’ll know if the signature isn’t trusted because GnuPG displays a warning:
gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.
In this case, make sure the key fingerprint is:
6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D
In order to get the fingerprint of the key which made the signature you downloaded (so that you can compare to the one above), look at the “key ID” is the output you got from
gpg --verify. It should be the same as in the example above. If not, don’t proceed to the installation and contact me. If it’s the same, get the fingerprint like this:
gpg --recv-keys 63E5E57D gpg --fingerprint 63E5E57D
Make sure the output matches the long fingerprint line above.
If everything went well, you can delete the .sig file. The next step is to install the .crt file.
Debian-based distributions, such as Trisquel, have a system list of trusted certificates, and you can add more manually. In order to add Rel4tion’s CA certificate do the following:
$ su # cp /home/joe/rel4tion-ca.crt /usr/local/share/ca-certificates # update-ca-certificates
You will see output like this:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... Adding debian:rel4tion-ca.pem done.
The permissions look like this:
# ls -l /usr/local/share/ca-certificates -rw-r--r-- 1 root staff 2667 Jul 14 11:43 rel4tion-ca.crt
Some programs don’t integrate well with the system, and maintain their own separate list of trusted CAs. For example, GNU IceCat and other Firefox derivatives are like this. If you use them, you’ll need to go to their Options and add the certificate there.