You are not logged in. Log in. Or Sign up.

NOTE: Federation is disabled on this instance!

You can test federation between the following instances:
Vervis @
HomeSharersfr33domloverReposrel4tion-wikiFilesmasteraccess tls.mdwn

Mirror of the Rel4tion website/wiki source, view at <>

[[ 🧙 fr33domlover ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🐔 Following] [🏗 Projects] [🗃 Repositories] [🔁 Workflows] [🐛 Tickets]
[[ 🗃 rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]


  • master
  • Tags

    master :: access /


    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.

    (1) Trusting Specific Certificates

    This is the best path for using Rel4tion’s server with SSL/TLS. Here are the options:

    1. Tell your browser (or Jabber client etc.) to trust the specific certificate (not the whole CA)
    2. Tell the browser/client to not verify the certificate. This is like the first option, but allows fake certificates to work without being detected, which is BAD. So the previous option is probably better.
    3. Use plain HTTP. For web browsing, it’s probably reasonable. For Jabber, Bitlbee, Mumble, etc. you’ll probably prefer one of the other options.

    (2) Trusting the CA

    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|]] 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?

    1. The text above
    2. It’s a workaround until the centralized broken CA system is replaced by a web-of-trust based protocol, such as [[!wikipedia Monkeysphere]].
    3. It’s an alternative to Monkeysphere, which isn’t widely used yet.
    4. Fighting for decentralization and freedom. Centralized commercial CAs want your personal information and trust you if you pay them. They trust even websites like g00gle known to spy and abuse. An independent CA only trusts friends etc., which is the way trust generally works between people.

    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
    2014-07-14 10:07:13 URL:
    [2667/2667] -> "rel4tion-ca.crt" [1]
    $ wget --no-verbose
    2014-07-14 10:07:13 URL:
    [287/287] -> "rel4tion-ca.crt.sig" [1]


    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 <>"
    gpg:                 aka "fr33domlover <>"
    gpg:                 aka "fr33domlover <>"

    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

    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

    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

    Specific Applications

    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.

    [See repo JSON]