Nathan's KB - log

openssl-self-ca

Anonymous (anonymous@undisclosed.example.com) — 2026-05-02T08:19:58+00:00

Self-hosted Root CA using OpenSSL

Do you hate how modern web browsers complain about using HTTP as if it's actually insecure to read plain text? It's extremely dumb to think that self-hosted infrastructure is insecure and must be accessed via HTTPS, especially when it's only accessible locally or via a VPN, but here we are.

Modern browsers block these “insecure” websites from accessing your camera, microphone, and even the clipboard, and some of these features may be important for some homelab applications. Thus the need for you becoming your own Root CA arrises.

Building the Certificate Authority

This is how you can run your own CA infrastructure easily using only the default install of OpenBSD 7. Unless otherwise noted all steps taken here assume the root folder of the CA resides in the /ca directory at the root of your system drive.

Creating the Folder Structure

A Trusted Root Certificate Authority is a serious business, so you should be serious about the organization of your operation, for this I have created the following folder structure to ensure the CA infrastructure that is built is actually scalable and organized:

mkdir /ca        # The root of our CA infrastructure.
mkdir /ca/root   # Stores the Root Certificate.
mkdir /ca/certs  # Stores the self-signed domain certificates we issue.
mkdir /ca/utils  # Contains utility scripts to manage our operation.

If you're following this guide, this folder structure is expected to be in place.

Getting a Root Certificate

The root certificate will be responsible for creating the chain of trust of all your issued certificates. It's also the only one that will have to be installed in your clients to allow them to accept your self-signed certificates for all your locally-hosted websites. To create a root certificate you'll have to do the following:

cd /ca/root
openssl genrsa -des3 -out root.key 2048
openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out root.pem

I won't pretend to understand exactly the implications of my decisions here in terms of parameters, but this should create a root certificate that will be good for 10 years.

Generating OpenSSL Configuration

The next step in achieving your status as a Trusted Certificate Authority is to create the OpenSSL configuration files used when generating new certificate requests. The OpenSSL certificate creation process must always go through a signing request procedure, even if you're doing so on the same machine.

This configuration file is the base of every certificate we generate and most of its contents are the same for every new request, so I have built this handy Perl script that takes care of the configuration file generation for you:

#!/usr/bin/env perl
 
# Save this script to /ca/utils/make-config.pl
 
=head1 DESCRIPTION
 
Builds the OpenSSL configuration file to request a certificate for a domain.
 
=cut
 
use warnings;
use strict;
use autodie;
 
use File::Basename;
 
# Main entry point.
sub main {
    if (scalar(@ARGV) != 1) {
        die "The domain name of the certificate must be provided.\n";
    }
 
    # Get the domain name.
    my $domain = $ARGV[0];
 
    # Remind the user that this tool always generates wild card certs.
    if (substr($domain, 0, 1) eq '*') {
        die "This tool generates wildcard certificates. Remove *.\n";
    }
 
    # Make the folder and write the configuration file.
    my ($cldomain, $folder) = make_folder($domain);
    open (my $fh, '>', "$folder/openssl.conf");
    print $fh build_config($domain);
    close $fh;
 
    print "$cldomain\n";
}
 
# Creates the folder for the certificate and config, and returns its path.
sub make_folder {
    my ($domain) = @_;
    my $cld = $domain;
 
    # Get the path to the certificate folder and make it.
    my $folder = dirname(dirname(__FILE__)) . "/certs/$cld";
    mkdir $folder;
 
    return ($cld, $folder);
}
 
# Builds the configuration for the certificate.
sub build_config {
    my ($domain) = @_;
 
    return <<"CONFIG";
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = XX
ST = Your State
L = Your Neighbourhood
O = Your Totally Legit Company
OU = CA
CN = *.$domain
[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = \@alt_names
[alt_names]
DNS.1 = $domain
DNS.2 = *.$domain
 
CONFIG
}
 
main();
 
__END__
 
=head1 AUTHOR
 
Nathan Campos <nathan@innoveworkshop.com>
 
=head1 COPYRIGHT
 
Copyright (c) 2024- Nathan Campos.
 
=cut

You should edit the contents of the configuration template just below the [req_distinguished_name] line to suit your environment. Be sure to be clever when populating these values in.

This script should be placed in the /ca/utils directory with the name make-config.pl so that the certificate issuing script can make use of it.

Issuing Certificates

Issuing a certificate using OpenSSL is a painful process and extremely easy to get wrong or simply get bored of typing a bunch of commands for something that you just want to get over with. Just like I did with the configuration file, here's a shell script that should automate the whole process for you:

#!/usr/local/bin/bash
 
# Ensure we stop on error.
set -e
 
# Ensure we have the right amount of command-line arguments.
if [[ $# -ne 2 ]]; then
    echo "usage: $0 <domain> <desc>" >&2
    exit 2
fi
 
# Create certificate directory and configuration file.
echo "Creating the configuration for the certificate request..."
CLDOMAIN=$(./utils/make-config.pl $1)
CERTDESC=$2
pushd "certs/$CLDOMAIN"
 
# Create the certificate request.
echo "Building private key and certificate request for $1 as $CLDOMAIN"
openssl genrsa -out "$CLDOMAIN.key" 2048
#openssl genrsa -des3 -out "$CLDOMAIN.key" 2048
openssl req -new -out request.csr -key "$CLDOMAIN.key" -config openssl.conf
 
# Create signed certificate.
echo "Signing certificate for 5 years..."
openssl x509 -req -in request.csr -CA ../../root/root.pem -CAkey ../../root/root.key \
    -CAcreateserial -out "$CLDOMAIN.crt" -days 1827 -sha256 \
    -extensions v3_req -extfile openssl.conf
 
# Packaging the certificate.
echo "Packaging the certificate in PKCS#12 format..."
openssl pkcs12 -export -out "$CLDOMAIN.p12" -inkey "$CLDOMAIN.key" -in "$CLDOMAIN.crt" -certfile "$CLDOMAIN.crt" -name "$CERTDESC"
 
# Extracting keys in SSH format.
echo "Extracting keys in SSH format..."
cat "$CLDOMAIN.key" | openssl rsa > id_rsa
openssl rsa -in id_rsa -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8 > id_rsa.pub
 
# Check our certificate.
echo "Checking the generated certificate..."
openssl verify -CAfile ../../root/root.pem "$CLDOMAIN.crt"
openssl x509 -text -noout -in "$CLDOMAIN.crt" | head -14
echo "..."
openssl x509 -text -noout -in "$CLDOMAIN.crt" | grep DNS
 
popd

This script should issue certificates that are valid for 5 years and exports the public and private keys to every format that you may need, so the generated certificate can be used for web servers, SSH, and basically anything under the sun.

As can be inferred from the usage line in the script, it takes a domain and a description. The description is a bit of text that's associated with the certificate and can be viewed by visitors of your website. The domain argument should not contain a wildcard since the make-config.pl script should take care of this automatically for you.

Adding SSL to Your Servers

The next logical step is to ensure that your servers can actually serve content with your self-signed certificates.

Nginx Proxy Manager

I like my home servers to be as easy to configure and maintain as possible, not to be the most secure or follow enterprise-grade best practices, so I use the humble Nginx Proxy Manager as the reverse proxy for all my self-hosted applications.

To add your self-signed certificates to your NPM instance you'll need to download the domain.crt and domain.key files from the CA server.

Inside NPM you'll navigate to the SSL Certificates tab and click Add SSL Certificate and select Custom. Now all you have to do is fill in the form with the following:

Name: Whatever you want
Certificate Key: domain.key
Certificate: domain.crt

The last step is to associate the newly added SSL certificate to the domain it belongs to in the Proxy Hosts page by selecting the proxy host you want to edit and going to the SSL tab.

Getting Clients to Trust You

Having your own CA is all well and good, but you need to ensure that your clients trust your self-signed certificates, for this you'll have to add the root.cer Root Certificate to the list of trusted sources in your clients, and this process is extremely different from system to system, and even may require you to add the certificate to individual applications such as web browsers.

Chromium and ChromeOS

On Chromium-based browsers and ChromeOS, you can add your Root Certificate by navigating to the Certificate Manager located at chrome://certificate-manager/localcerts and in the Custom section, click on the Installed by you card.

In the next window, you should import the root.cer certificate file to the Trusted Certificates section. You should now be able to access your self-hosted services using the needlessly complex HTTPS.

Windows

Adding the generated root certificate under Windows involves opening the certlm.msc MMC Plug-In and right-clicking the Trusted Root Certification Authorities folder. In the context menu, you should select All Tasks > Import… and follow the wizard, eventually browsing to the root.cer certificate file and importing it. While in the wizard, ensure that the “Local Machine” option is selected as the Store Location, since this will ensure that the Root Certificate Authority is trusted system-wide.

Linux

First make sure you rename the root.cer file to root.crt, since it's required to have the crt extension for it to be picked up by the certificate manager. Then run the following commands as root to move the file to its appropriate place and reload the certificate store:

mkdir -p /usr/local/share/ca-certificates/homelab
cp root.crt /usr/local/share/ca-certificates/homelab/
update-ca-certificates

php-windows

Anonymous (anonymous@undisclosed.example.com) — 2025-07-28T08:11:54+00:00

PHP 5.6 on Windows Server 2008 and IIS

For the Old Computer Challenge 2025 I had the amazing idea that I wanted to have an old HP t5740 thin client as a public web server on the internet, running Windows Server 2008 and IIS. The goal was to host my own website on it, which requires at least PHP 5.6.

Since running PHP under IIS was never a straightforward process, although Microsoft did make it easy with the Microsoft Web Platform Installer 2.0, now days everything has been taken down and a bunch of information and archives are no longer available, so I decided to log my successful steps here in case anyone ever wants to replicate this in the future.

Prerequisites

This is an old system, and with older systems you need a great deal of responsibility, specially if you're going to expose any part of them to the public internet. Before continuing ensure that you have fully updated Server 2008 using Legacy Update, since out-of-the-box Windows Update won't work because of older TLS versions and expired certificates.

It's important to note that in order for PHP to run you do need to install the Microsoft Visual C++ 2012 Redistributable files. These are required since PHP was compiled with that version of Visual C++. Since a lot of software requires different versions of the redistributable files, my recommendation is always to install TechPowerUp's Visual C++ Redistributable Runtimes All-in-One pack, this will ensure you have all possible versions installed and save you from many headaches down the line.

Setting up FTP

Since nothing in Windows can be straightforward, the first problem started when I needed to enable FTP access so that I could send files to the server quickly for installation. This became a problem because as soon as I tried to do a directory listing after connecting to the FTP server it would hang indefinitely.

The reason for this was that Windows Firewall was blocking communication over the FTP passive ports. I tried using active mode and it worked perfectly fine, but since I wanted passive mode working, since that's easier to manage over all my machines, I had to resort to IIS 6 administration scripts and magic to get everyone happy. The fix involves limiting the port range of IIS's FTP server and allowing those specific ports through the firewall. This has the side-effect of limiting how many users you can have connected simultaneously.

The fix involves running the following IIS administration script (ensure you have installed the IIS 6 Scripting Tools role) and specifying the desired port range:

C:\Inetpub\AdminiScripts\adsutil.vbs set /MSFTPSVC/PassivePortRange "5500-5520"

Next step is simply going into the Windows Firewall settings and allowing Inbound Traffic through those ports.

Getting PHP Binaries

Since the last PHP 5 for Windows binaries are absent from the PHP Museum Archives, I had to use the Wayback Machine to fetch PHP 5.6.40 for Windows, the last version of the PHP 5 branch. In my case, since I'm running a 32-bit copy of Server 2008, I downloaded the VC11 x86 Non Thread Safe (2019-Jan-10 00:38:30) version.

Installing PHP

Next logical step was installing PHP 5.6, which in the case of Windows and IIS, requires a manual installation procedure.

Manually installing simply means that you have to unpack the ZIP archive of the PHP distribution onto a folder, usually C:\php, set the PATH system environment variable to point to this directory, and rename one of the included configuration file examples to php.ini.

A step that's needed is to set the following configuration variables accordingly:

fastcgi.impersonate = 1
fastcgi.logging = 0
cgi.fix_pathinfo=1
cgi.force_redirect = 0

This configuration is apparently required in order for PHP to work under IIS, at least according to the documentation.

Setting up IIS

The next logical step is to setup IIS 7 so that it can properly handle *.php files and execute the CGI handler. For the first step, following the tutorial, you should setup the Handler Mappings for PHP in the following manner:

Next, in order for index.php files to get preference over other index files, you should open the Default Document view in the IIS server manager and add the index.php directive there. Move it up or down according to your preference of priority.

References

The following main tutorials by the PHP foundation were followed in order to have this up and running. These articles had to be fetched using the Wayback Machine since PHP already has taken them down in recent years.

public-local-server

Anonymous (anonymous@undisclosed.example.com) — 2025-08-23T09:12:48+00:00

Exposing a Local Server to the Public Internet Safely

These are the steps I took in order to securely expose a local server on my network to the wild west of the public internet, allowing me to free myself from cloud providers and properly self-host everything (with a small exception).

In this log/tutorial you will notice that I don't talk about how to secure the network that a “semi public-facing” device is in. The reason for this is that everyone's network is different, and in my specific case, all devices that are going to be proxied to the outside world will be on a physically separate network (5G modem in my case), thus I don't have to worry about having a compromised device on my home's network.

Bridge VPN

In order to ensure that I don't have any open ports on my home router and no public internet traffic flowing through my home network, I've decided to use a VPN and a cloud VPS (the only exception to the self-hosting everything rule) to provide a secure tunnel for traffic to flow through. This was done using the amazing SoftEther VPN project, which apart from Wireguard and Tailscale, is in my opinion the best VPN software in the market.

Setting up the Server

To set the VPN software up on a Hetzner VPS in Local Bridge mode in order to avoid the bottleneck of SecureNAT, I've followed the following tutorial. Since Hetzner VPSes by default use DHCP for IPv4 address attribution, this will conflict with the DHCP server we need to install in order to run the local bridge, so following this Hetzner tutorial for static IP configuration is required in order for the setup to work.

Since I wasn't able to get the DHCP server using dnsmasq to work no matter what I tried, I had to enable SecureNAT on the server, but disabling the Virtual NAT which is the extremely slow layer that greatly impacts performance, thus only using the DHCP server. The configuration used was the following:

Since we are using a DHCP server to hand out IPs in our VPN we need to ensure that the server also has an IP assigned to the TAP interface that it's using to communicate within the VPN's network. This can be tested by running dhclient tap_vpn, where tap_vpn is the VPN's TAP interface name, and later making this change permanent by adding the following to your /etc/network/interfaces file (assuming Debian):

auto tap_vpn
allow-hotplug tap_vpn
iface tap_vpn inet dhcp

The last step in the server side of things is to ensure that systemd can properly start the server upon a system start. Since all tutorials on the internet are still using initd, here I have the systemd unit file that I used, which was taken from the softether-vpnserver Debian package and slightly modified:

[Unit]
Description=SoftEther VPN Server
After=network.target auditd.service
 
[Service]
Type=forking
TasksMax=16777216
ExecStart=/root/vpnserver/vpnserver start
ExecStop=/root/vpnserver/vpnserver stop
KillMode=process
Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SYS_NICE CAP_SYSLOG CAP_SETUID
 
[Install]
WantedBy=multi-user.target

After all of these changes a reboot should be done on the server just to ensure that everything comes up automatically and works.

Securing the VPN Network

Since there will be different types of users on this VPN, it's important to create some groups, at least one for your public-facing servers and another one for all your local servers. This will make ACLs much easier to create and manage. Also ensure that your servers are all authenticating with extremely strong passwords or client certificates.

It's also important to ensure that, if a system on your VPN's network becomes compromised, that an attacker isn't able to use it to jump to other nodes on your VPN, specially the internet facing server. For this, a simple but effective measure would be to setup some Access List rules blocking traffic that could be used to compromise other systems.

Reverse Proxy

Since we are not exposing our local network directly to the open internet by means of port forwarding, we will require a reverse proxy server that is exposed to the internet. In this case I have a Hetzner VPS running Debian and nginx, this is the simplest and most flexible setup for a reverse proxy. Even though I have many years of experience with Apache and have been a bit reluctant to move to nginx, this is the perfect use for it, after all it was initially developed as a reverse proxy. It's super performant as a reverse proxy, easy to configure, integrates well with certbot, and can proxy raw TCP/UDP streams.

Setup for HTTP(S)

Setting up nginx for HTTP(S) traffic is super simple, all we need is nginx itself and certbot installed, after these are installed it's a simple matter of configuring virtual hosts for each site we wish to serve. For each site you want to configure you need to create a new file under /etc/nginx/sites-available/ with the following content:

server {
    listen 80;
    listen [::]:80;
 
    server_name domain.tld www.domain.tld;
 
    location / {
        proxy_pass http://ip_vpn_local:80;
        include proxy_params;
    }
}

To enable this virtual host we need to symlink it to the /etc/nginx/sites-enabled/ and restart the web server:

ln -sf /etc/nginx/sites-available/yourdomain /etc/nginx/sites-enabled/
systemctl restart nginx

This is all it takes to reverse proxy an HTTP website. Now for enabling HTTPS so that modern, pedantic and useless, browsers can access our website without complaining:

apt install certbot python3-certbot-nginx
certbot --nginx --no-redirect
systemctl reload nginx

Follow the wizard for certbot and you should now have a website that has HTTPS active and won't automatically redirect to it, so that older browsers are still able to access your website without requiring useless encryption.

Setup for TCP

Setting up nginx for proxying TCP streams is even easier than for HTTP. This is useful for things like Gopher. To set this up you need to install the stream module for nginx:

apt install libnginx-mod-stream

Next you should edit your /etc/nginx/nginx.conf and append the following at the end of the file:

stream {
    server {
        listen 70;
        listen [::]:70;
 
        proxy_pass ip_vpn_local:70;
    }
}

It's important to note that this needs to go in your /etc/nginx/nginx.conf below the http {} directive and that, as usual, a restart of the web server is required.

uz801-openwrt

Anonymous (anonymous@undisclosed.example.com) — 2025-08-20T15:06:49+00:00

Running OpenWRT on a UZ801 USB 4G Modem

This is a log of everything I did to get OpenWRT running on a generic UZ801 USB 4G modem with the Qualcomm MSM8916 SoC.

All of this was done on macOS Monterey, so keep that in mind when following this log, and ensure that you use commands that are appropriate to your platform.

Prerequisites

These are the most basic things that you'll need to get started on this endeavour:

These can be easily installed, but edl will require the following to be installed on your system:

git clone https://github.com/bkerler/edl.git
cd edl
git submodule update --init --recursive
python3 setup.py build
sudo python3 setup.py install

Getting ADB Access

By default you won't have adb access to your 4G dongle, this isn't described in many places on the internet, and took me a while to figure out, but this tutorial showed that, in order to enable adb on newer versions of the firmware, you need to access the following URL in the web administration console: http://192.168.100.1/usbdebug.html

Backup Firmware

To ensure that any further modifications we do in the future are safe and can be reverted in case of crashes perform the following commands to backup the stock firmware of your device:

adb reboot edl
python3 edl.py rf uz801_backup.bin

This will take a couple of minutes to finish, but you should now have a full dump of the device's firmware which can be restored with the following command:

python3 edl.py wf uz801_backup.bin

OpenWRT Flashing

OpenWRT on this platform is supported by a fork from AlienWolfX, this is the base that was used. To get the latest version of the compiled firmware files you go to the repository's Releases page and look for the latest OpenWRT release there, then it's a matter of running the included flash.sh script, which I have reproduced here for transparency reasons:

echo '============================='
echo '       OpenWRT Installer     '
echo 'https://github.com/AlienWolfX'
echo '============================='
echo 'Rebooting to bootloader..'
adb reboot bootloader
echo 'Done.'
sleep 5
 
fastboot erase boot
fastboot flash aboot aboot.bin
fastboot reboot
echo 'Done.'
sleep 5
 
fastboot oem dump fsc && fastboot get_staged fsc.bin
fastboot oem dump fsg && fastboot get_staged fsg.bin
fastboot oem dump modemst1 && fastboot get_staged modemst1.bin
fastboot oem dump modemst2 && fastboot get_staged modemst2.bin
fastboot erase boot
fastboot reboot bootloader
echo 'Done.'
sleep 5
 
fastboot flash partition gpt_both0.bin
fastboot flash hyp hyp.mbn
fastboot flash rpm rpm.mbn
fastboot flash sbl1 sbl1.mbn
fastboot flash tz tz.mbn
fastboot flash fsc fsc.bin
fastboot flash fsg fsg.bin
fastboot flash modemst1 modemst1.bin
fastboot flash modemst2 modemst2.bin
fastboot flash aboot aboot.bin
fastboot flash cdt sbc_1.0_8016.bin
fastboot erase boot
fastboot erase rootfs
fastboot flash boot boot.img
fastboot flash rootfs rootfs.img
echo 'Done.'
sleep 2
 
echo 'Rebooting to system..'
fastboot reboot
echo 'All Done! you can access your device now.'
sleep 5

You should now have OpenWRT fully working and accessible at http://192.168.1.1

Fix USB Tethering (RNDIS)

After flashing OpenWRT I had issues with Windows 7 (yes, that's the only computer I had on hand with Windows to test quickly) not recognizing the RNDIS driver for USB tethering. I was able to get it working after finding this issue which linked to this XDA Developers post.

Since I no longer trust the new XDA Developers website owners to keep the site up in the future, here are the steps to fix this:

Go to Device Manager and find the RNDIS device that's currently unknown
Right-click and select “Update Drivers”
Choose to browse for the driver and select the “Let me pick from a list of device drivers” option
Select “Network Adapters”
Select “Microsoft Corporation” not Microsoft
Finally select “Remote NDIS based Internet Sharing Device”

You should now have everything setup and working.

Nathan's KB - log

openssl-self-ca

Self-hosted Root CA using OpenSSL

Building the Certificate Authority

Creating the Folder Structure

Getting a Root Certificate

Generating OpenSSL Configuration

Issuing Certificates

Adding SSL to Your Servers

Nginx Proxy Manager

Getting Clients to Trust You

Chromium and ChromeOS

Windows

Linux

php-windows

PHP 5.6 on Windows Server 2008 and IIS

Prerequisites

Setting up FTP

Getting PHP Binaries

Installing PHP

Setting up IIS

References

public-local-server

Exposing a Local Server to the Public Internet Safely

Bridge VPN

Setting up the Server

Securing the VPN Network

Reverse Proxy

Setup for HTTP(S)

Setup for TCP

uz801-openwrt

Running OpenWRT on a UZ801 USB 4G Modem

Prerequisites

Getting ADB Access

Backup Firmware

OpenWRT Flashing

Fix USB Tethering (RNDIS)

See Also