Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

[[ 🗃 ^yEzqv rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

Tags

master :: projects / systems / diaries /

ssl.mdwn

2014-05-25

This is helping me a lot: http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL.

I’m creating a self-signed SSL certificate which will hold for one year. There will be a separate certificate for each service and each host. For lighttpd, here is a suggested location:

/etc/lighttpd/ssl/www.example.org.pem

At the moment the webserver serves the following clients:

I’m not an expert in this area, so I’m not sure how bad it would be to use a single certificate for everything. I do know A/I has an imtermediate CA which allows having as many certificates as they wish, and Riseup has separate certificates at least for the Tor hidden services.

As far as I understand, having a single certificate means that if security is compromised, it affects all my hosts immediately. Using separate certificates means one doesn’t affect the other. However, with Monkeysphere the same PGP key may be used to sign them all, and then that single key is a potential point of failure. However, in case I ever have problems with Monkeysphere, it’s nice to have regular SSL as backup. PGP key signatures may be revoked, so I guess I’ll be fine. At least until I learn more about SSL and OpenPGP.

Encryption requirements:

Tor requires some extra reading. I’ll take care of it later. Right now I want to do filtering in the server config based on hostname (SNI makes it possible).

Here’s what we need to do:

Checking ikiwiki… ‘sslcookie’ is indeed set to 0 (i.e. false) by default.

Not opening port 443 for now, to see if it’s required.

Now let’s enable SSL. Basically two lines are needed for this:

ssl.engine = "enable" 
ssl.pemfile = "/path/to/server.pem"

For partager.null I’m adding the following text right under the global server config:

[[!format perl """ $HTTP[“host”] == “www.partager.null” { ssl.engine = “enable” ssl.pemfile = “/etc/lighttpd/ssl/www.partager.null.pem” } """]]

For git.partager.null, this will be under the Gitweb host config:

[[!format perl """ $HTTP[“host”] == “git.partager.null” { ssl.engine = “enable” ssl.pemfile = “/etc/lighttpd/ssl/git.partager.null.pem” } """]]

I’m still not sure it’s valid to have two $HTTP[“host”] sections, one inside the other. I’ll see when I realod the server config.

Now let’s generate SSL certificates, handle their file permissions and make sure the hostname is correct when generating…

2014-05-26

Unless I missed something, I didn’t find any mention of the hostname in the man page. I’ll just the the ssl command and see what happens:

openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Done with certificates.

Done with initial Monkeysphere support.

Time to test! Also, now opening port 443 in firewall…

2014-05-27

I need to create an SSL certificate from the PGP key, or revoke the PGP key and create a new one from the certificate. For now I disabled SSL completely. See here:

http://web.monkeysphere.info/doc/host-keys/

2014-06-08

I want to create my own CA, so that I can easily create signed certificates and allow people to access the website even without Monkeysphere. Whether it’s okay to enforce HTTPS for non-I2P access, I’ll decide when the CA works.

I installed these:

I think I’ll start with TinyCA, which seems to be getting positive opinions. I got this on IRC: “if you’re operating a CA, i recommend doing it on a well-secured machine, as a non-privileged user”. Naturally, managing the CA as my own user is dangerous. I thought root would be a good idea, but I guess it’s dangerous too.

Since home server operators don’t have all the resources commercial providers have… I think my solution to this issue will be to create a new unprivileged user and have that user run the TinyCA application. Then, the certificates can be copied to where other users will use them in read-only mode.

First I need to make sure I can make that user run a GUI program… it’s okay if it requires a login: I can log in as two users in parallel. But let’s try and see first. I’ll adapt the command I used for the other users. This is the command I used for ikiwiki:

# adduser \
    --system \
    --shell /bin/bash \
    --gecos 'ikiwiki instance user' \
    --group \
    --disabled-password \
    --home /home/ikiwiki \
    ikiwiki

I’ll try a similar command for the CA user:

# adduser \
    --system \
    --shell /bin/bash \
    --gecos 'certificate authority user' \
    --group \
    --disabled-password \
    --home /home/ca \
    ca

The user can be deleted with:

deluser --system --remove-home ca

Also, after creation and probably when new files are added, the permissions should be fixed if needed, so that nobody can access the ca user’s files, not even read them or list them.

2014-07-05

It’s time to try. I’m not sure whether it makes a difference to make the new user a system user, but I’ll try and see what happens. I can always make it a regular one, with password disabled… I think.

Running ca user command above… done.

Now trying this:

$ su
# su - ca
$ tinyca2

I got this:

Gtk-WARNING **: cannot open display: :0.0 at /usr/lib/perl5/Gtk2.pm line 138

In other words, I need X runnning. Trying the following:

Okay, running X that way works. But it loads GNOME 3, not XFCE (probably a matter of default config). Also, I can’t move to other terminals because then X outputs some errors and I don’t know how to get the display again. It means I can’t access my open web browser and my text editor for documenting the process here.

IDEA: I’ll open a Midori instance there and Mousepad, and later move the text file back here to me.

Working on it…

Success! I created just a root CA for now. I’ll need to create an SSL “policy” page on the wiki later, and a subdomain cert.partager.null with a revocation list.

NEXT: Proceed according to the guide. And PUT ALL THE LINKS HERE, SO LATER I CAN WRITE A GUIDE FOR THE WIKI TOO. Actually, the best thing is to start writing it now, as I go through these steps.

2014-07-06

The actual TinyCA guide is in the second link.

Going back to CA user to finish the work…

I created CA cert, www.partager.null key and revocation list.

2014-07-20

SSL is working, but there’s an issue on the wiki: I want to write a task “add SSL certificates for all domains, including the git and ftp pages”. The problem is that I don’t leave space for development: There’s the Servers page with categories, but e.g. Certificates is just a Partager user guide, without space for things like admin info (e.g. guide for me, explaining how to maintain things). First, the task:

[[TODO|TODO/OPEN]] add SSL certs for all domains

Now, here are ideas. [[TODO|TODO/OPEN]]. Combine this with wiki-reorganization in my personal area.

[[TODO|TODO/OPEN]] when I’m done with the above, go over this diary. Either remove it

[See repo JSON]