Openssl - setting up a custom CA certificate, requesting and approving certificates with Subject Alternative Name (SAN)

I spent last couple of hours reading web resources, man pages and config files to get what I need: a custom CA setup that allows me to sign certificate request which include Subject Alternative Name (SAN) extensions.

Setup custom CA certificate

I started with the Ubuntu certificates guide. It explains how to setup the custom CA. I used the instructions in there, but I decided to use the default Ubuntu CA setup (which used /etc/ssl/demoCA directory).
First I edited /etc/ssl/openssl.cnf. In the CA_default section:
- I changed dir = ./demoCA to dir = /etc/ssl/demoCA (this is so that I can run openssl ca from any directory without entering full paths)
- I uncommented copy_extensions = copy  (this is required so that I can include in certificates SANs from their certificate requests)

In the req section:
- I uncommented req_extensions = v3_req

In the v3_req section
- I added subjectAltName = $ENV::subjectAltName so that I can pass SAN content via environmental variables (I found this trick somewhere on the internet, in order to avoid writing them in config files).


Finally I ran following commands to create the required files:

sudo mkdir /etc/ssl/demoCA
cd /etc/ssl/demoCA
sudo sh -c "echo '01' > serial"
sudo touch index.txt
sudo mkdir private newcerts
sudo chown 700 private newcerts
sudo openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650 -newkey rsa:2048

Create a certificate with SAN

As indicated in the Ubuntu docs (and lots of other places):

openssl genrsa -des3 -out server.key 2048
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
env 'subjectAltName=DNS:testbox.local' openssl req -reqexts v3_req -new -key server.key -out server.csr
openssl req -in server.csr -noout -text
sudo env 'subjectAltName=DNS:testbox.local' openssl ca -in server.csr 

The signed certificate will be saved in /etc/ssl/demoCA/newcerts/.

Improving OpenVPN thoughput

I recently faced an unusual problem (for me): an OpenVPN connection going via TCP over a fast network, which had transfered speeds of less than 2KB/s. Although I tested some other options (compression on/off, UDP, etc), none of them proved significantly faster. Moreover, I has hoping to fix the problem with as few as possible changes to clients.
Some time ago, I red about optimizing OpenVPN over Gbit networks. That post covers optimizations related to CPU bottleneck (hardware SSL support, different ciphers, etc). This was certainly not the case for me, since boxes linked via OpenVPN were mostly idle. However, that post has a very brief and accurate explanation and statement about how OpenVPN works, i.e. the data flow between source and destination.
So based on that post, I decided to try mssfix 0 (ie. disable OpenVPN packet fragmenting and leave the kernel/driver do that) and to increase tun-mtu parameter to help test speed improvements. I increased it to 32000 and I got about 150KB/s speed, then to 48000 and I got about 250KB/s, then to 60000 and I got 300KB/s. I thought "what if ...?" and I raised it to 65500. Amazingly, I got average speeds of 1.25MB/s with top speeds above 2.5MB/s.
That was cool, but had one downside: the VPN connection become unstable, with the tun0 device disappearing from the server (probably because the process that managed it crashed).
Reading further in OpenVPN man page and other posts, I decided that I should try to use OpenVPN's mssfix feature. Default value is 1500, but OpenVPN automatically reduces that in order to allow for the SSL data overhead. I decided to be on the safe size and use mssfix 1440. Heuristically, I thought I should use a tun-mtu that is a multiple of that (to help split the data in even fully-filled packets). So I used tun-mtu 64800. With these two settings on, the server proved stable and average transfer speeds went to about 850KB/s (good enough for my needs).
I should not that these transfer speeds were obtained by applying the same settings:

tun-mtu 64800
mssfix 1440

in the client config. If no changes are applied to the client configs, the transfer speed will be still unacceptable low, but still higher than before (about 5KB/s).

Is there any design behind Python language?

I gave Python another try (fourth or so). In the past I found it to be a terrible designed language. Lots of things in the language itself felt like they were scraped from all other existing programming languages. And the worst part, that it didn't feel familiar at all, even if you know those languages.

This time I tried Python 3. I went with the Dive Into Python 3 book (ofcourse).

Some of the weirdest things I noticed while reading:
1. Python's goal was to be a programming language that is as easy to read as plain English, right? Then why use def instead of define, why use try...except instead of try...exception. I mean, unless you know what try...except does, you'll think it will try to do something, except some other thing.

2. You add items to lists using list method like a_list.insert(), or a_list.append(), but you delete them using del keywork (del a_list[0]). What is that?

3. You define tuples with (1, 2), but (1) is not a tuple because ( ) are used for math. You need to write (1,). Makes sense, but whoever added the tuples feature did not see this coming? Were they not enough symbols on the keyboard that they had to recycle ( )?

4. You define sets with {1, 2}, but {} is a dictionary. What? Yes, for empty sets you need set().

5. Printing an empty list shows [], an empty tuple shows (), an empty dict shows {}, but and empty set shows... set()? boooh!

6. Lists have extend() and append() methods, but sets have update() and add().

7. List don't have discard() method (i.e. like remove() but doesn't raise exception), but sets do. Logic for that is?

List goes on, but I got tired of keeping track. I finished reading the book eventually (quite fast I would say considering my "go away Python" bias)  and I have to admin Python 3 is much better designed than 2.

However, it wasn't the language itself that got me hooked on the book, but it was the book itself. It's full of non-Python related technical info and generic programming tips. It ties well to other topics without going into much detail. I recommend reading it.