This post is now superceded by a friendlier and more eficient method: https://ducakedhare.co.uk/?p=1512

The following are a bunch of quick notes about setting up security certificates, enabling OpenVPN and forcing all traffic through a VPN tunnel, and adding SSL

It’s all tailored for Ubuntu 12.04 / 14.04 servers, and exists primarily as learning notes. I may or may not come to cleaning them up.

OpenVPN details and dialectic can be found at https://help.ubuntu.com/14.04/serverguide/openvpn.html

Longer description of Apache SSL activation can be fouind here https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-12-04

Key signing – how it works

This section is very simplified. See https://en.wikipedia.org/wiki/Certificate_authority for technical details.

A Certificate Authority is an organisation we trust to confirm we can trust other people’s certificates.

A key and certificate for trusting are created: the Certificate Authority’s ca.key and ca.crt

ca.crt is given to anybody to say “I am the CA, anything coming from me is trusted.” Like a hologram on an ID sheet.

ca.key is used to confirm that CA has approved whatever the key is used to sign, like a hologram-creating machine, with the hologram blueprint. The key is used to say “We, CA, confirm that the item we hereby sign is genuine.”

Let’s saqy that we trust CA.

Now a server, say FantasticDotCom comes along and says, “I want CA to confirm that I am legit.”

FantasticDotCom creates a fantastic.key with which it can start affirming with. It then creates a fantastic.csr – a Certificate Signing Request – that it sends to CA.

CA processes fantastic.csr with its ca.key to produce a new file, fantastic.crt.

The fantastic.crt certificate has been signed by CA- which means that fantastic.crt is trusted by CA to do Everything Right.

Since we already trust CA, we can trust FantasticDotCom

If FantasticDotCom then tells us “my product that I signed with my own fantastic.key is legit”, we know that we trust the product signed by Fantstic, who is endorsed in turn by CA.

The importance of the KEY files is to be noted: only Fantastic must be able to sign with the fantastic.key and only the CA must be able to sign with the ca.key

If MrNasty got a hold of fantastic.key, we would not be able to tell if a product purportedly endorsed by FantasticDotCom really was genuine.

If MrNasty got a hold of ca.key, he could cause CA to endorse any number of NefariousDotCom and EvilDotNet certificates as he liked.

To rectify this, CA would need to revoke ca.key and anything that was signed with it, including alFantasticDotCom keys and anything underneath them, then create a new ca2.key and ca2.crt, ask everyone to stop trusting ca.crt and start trusting ca2.crt, and re-sign fantastic.csr again to produce a different fantastic.crt, which we could then trust.

Examples of real-world CAs are VeriSign, GlobalSign and CASC

Certificate & Key generation

Become root

su

Install required software

apt-get install openvpn

Setup Easy RSA from OpenVPN

Tasks: setup a certifying authority certificate

Switch dir

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

Edit vars

edit ./vars

set the KEY_* params: Country, Province, City, Org, Email

Process parameters

source vars
./clean-all
./build-ca

Now the Certificate Authority certificate should be created.

Generate Keys

Server key

./build-key-server <SERVERNAME>

This key is to be used to authenticate a server. Create as many as necessary (node01, node02)

Client key

./build-key <USERID>

Key identifying a client

Create one per identity (computer, user, app, etc)

Diffie Helman parameters

Not sure what this is used for… Used in OpenVPN configuration (not necessary for Apache/SSL)

./build-dh

Overview of contents now in ./keys/

*.crt → these files are certificates. Entities show these publicly to others to say “I am who I am”

*.key → these files are keys that guarantee the certificates. Entities must keep these secret. Do not share.

*.csr → certificate signing request. Not needed right now, but in other use cases. See below.

ca.crt → this certificate is the certificate authority. Add this certificate to a client so that any sub-certificate signed with ca.key can be trusted.

ca.key → the key used to sign other certificates. SUPER-SECRET. Compromising ca.key renders the chain of trust based on that ca.key useless.

Alternatives

Self-sign in one line:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout <keypath> -out <crtpath>

or – Create a CSR and sign it on a different server [notes to come]

Adding the key to Apache

Install apache

apt-get install apache2

a2enmod ssl

service apache2 restart

Edit SSL config

nano /etc/apache2/sites-available/default-ssl

Adjust the email

Under the email add

ServerName <SERVERNAME>:443

For example “ServerName example.com:443”

Set keys

SSLEngine on

SSLCertificateFile <crtpath>

SSLCertificateKeyFile <keypath>

(replace paths as appropriate)

a2ensite default-ssl

service apache2 reload

You can now access your website via HTTPS:// as well as HTTP://

Disable default to disable regulat HTTP access.

OpenVPN enablement

Get the server configuration

Go to

cd /usr/share/doc/openvpn/sample-config-files

gunzip server.conf.gz

Edit server.conf – note the port (1194 for ex)

Edit the sections:

ca → ca.crt path

cert → server.crt path

key → server.key path

dh → dh1024.pem path

Edit the “server” property to give it an address in the right local-network range:

10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255

192.168.0.0 – 192.168.255.255

Use appropriate network mask. Example 10.9.8.0/0.255.255.255 so that the VPN server will assign addresses in the range 10.9.8.* to connecting clients

Uncomment out the “user nobody” and “group nobody” lines to run openvpn without provileges and improve security

Client setup

Install OpenVPN on client, and go to cd /usr/share/doc/openvpn/sample-config-files and edit client.conf

Update the keys

ca → ca.crt path

cert → client.crt path

key → client.key path (client’s key to identify itself, keep secret!)

Edit the “remote” directive to specify the public IP address of the server.

Start

On the server run:

openvpn server.conf

On the client run:

openvpn client.conf

Tunnel all client traffic through the VPN

By default, the setup allows the client to access the internet as itself from home, and also access to the internal network of the VPN.

To make the client look like it’s coming from inside the VPN network, we need to modify a few things in the firewall

# open the OpenVPN port
iptables -A INPUT -p udp --dport 1194 -j ACCEPT

# perform network address translation
iptables -t nat -A POSTROUTING -s 10.9.8.0/24 -o eth0 -j MASQUERADE

# forward TUN interface to eth0
iptables -A INPUT -i tun+ -s 10.9.8.0/255.255.25.0 -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

Run this along with other firewall iptables rules.

Appendix – iptables script

I run this script as root to change my firewall settings, and store it as a script in ~/bin

Add lines, comment out lines etc to switch things on and off.

# See http://wiki.centos.org/HowTos/Network/IPTables 
# for more info

# [1] if we have connected from a remote machine - make sure
#    we maintain connection!
# add a live rule
iptables -P INPUT ACCEPT

# [2] flush current rules table, which closes all external
#   connections - hence step 1.
iptables -F

# [3] add our first rule on incoming connections:
# "-m state" load module state
# "--state ESTABLISHED,RELATED" any connections that originated
#     from us
# "-j ACCEPT" jump to setting the target action, which is ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# [4] Accept any input for protocol ("-p") ICMP
iptables -A INPUT -p icmp -j ACCEPT

# [5] Accept anything from localhost -- the distinction is not visible in the above dump
iptables -A INPUT -i lo -j ACCEPT

# [6] Accept incoming new ssh (tcp port 22) connections ; existing ones are served by rule [3]
iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT

# [6.1] XTRA - allow other connections
iptables -A INPUT -m state --state NEW -p tcp --dport 80   -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443   -j ACCEPT
# iptables -A INPUT -m state --state NEW -p tcp --dport 8080   -j ACCEPT
# iptables -A INPUT -m state --state NEW -p tcp --dport 21   -j ACCEPT
# iptables -A INPUT -m state --state NEW -p tcp --dport 3306 -j ACCEPT
#     port 80 is for Apache; 3306 is for MySQL, for example.

# ========= OpenVPN configurations
# open the OpenVPN port
iptables -A INPUT -p udp --dport 1194 -j ACCEPT

#  perform network address translation
iptables -t nat -A POSTROUTING -s 10.9.8.0/24 -o eth0 -j MASQUERADE

# redirect DNS requersts straight to DNS server
# iptables -t nat -A PREROUTING -i tun+ -p udp --dport 53 -j DNAT --to-destination 8.8.8.8

# forward TUN interface to eth0
iptables -A INPUT -i tun+ -s 10.9.8.0/255.255.25.0 -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

# ========== /OpenVPN

#iptables -A INPUT -m state --state NEW -p tcp --dport 1022 -j ACCEPT
# open for additional SSH during upgrade

# [7] Reject everything else
# iptables -A INPUT -j REJECT # original setup
iptables -P INPUT DROP # the more correct step

# [8] Reject all forwards (we are not a router)
# iptables -A FORWARD -j REJECT # original setup
iptables -P FORWARD DROP # the more correct step
#iptables -P FORWARD ACCEPT # VPN tunnel passthru

# [9] Accept any outgoing traffic
iptables -P OUTPUT ACCEPT

# [10] Save the settings we've just defined so that
# they apply when we reboot
# service iptables save
iptables-save