We also qualify for fiber internet at the new apartment, and I could get near gigabit speeds for $55/month through RCN. I wanted to be able get that internet speed and come close to taking advantage of it on my network. Therefore, my requirements became a gigabit ethernet network for the home, plus wifi that is as reasonably fast as possible with good coverage of the whole apartment, including the back patio.

I also wanted to be able to VLAN segment my network and have separate wifi networks or SSIDs for each VLAN. I wanted to keep my smart devices from communicating with my personal devices, unless they needed to to perform a smart function. This requirement basically bumped me into small business / prosumer hardware, unfortunately.

I started looking at wifi, because this is really the only place I knew to look. I quickly decided I needed a Wifi 6 router, the latest and greatest protocol for the fastest speeds and most clients. Functionally this meant faster connection to my laptop and phone, since I was planning to hardwire the TV for streaming. The next questions were mesh or not? And do I want a separate router and access point (AP)?

I initially decided not to go for a mesh system, instead going for the cheapest Wifi 6 router I could find, this ASUS router. I planned to put it in AP mode and use a separate router for my VLANs and other traffic routing. This was a great plan until I realized you needed multi-SSID and VLAN support in the AP in order to have wifi devices on different networks. This meant to keep my light bulbs from hacking into my laptop, I needed an AP with VLAN and multi-SSID support. This directed me to the Orbi Pro Mini Wifi 6. This router was on sale I think at Micro Center because it had all the features I wanted, plus a mesh satellite, for only $40 more than the cheap ASUS. So this got me my AP for the network.

Next was the router / switches. I had decided in deciding my wifi AP that I would use a separate gigabit router for my network. This was motivated by getting a cheap Wifi 6 router and getting the rest of the required features from the router. When I upgraded to the Orbi, I didn’t reconsider my router choice. My system is working well for me, but I think I could maybe have used the Orbi for everything and skipped the separate router. Anyway. My router handles the most of the work for the network, and the Orbi APs give me multiple SSIDs to keep my devices separate.

I also used CAT6 cabling for all the runs between devices the the router. This lets me get gigabit speeds, fully capable of taking advantage of my fiber internet, anywhere with an ethernet cable. Currently I have a direct line to my home server, the Apple TV, and one under the couch for working in front of the TV. I also have my docking station hardwired in. This keeps me covered with fast internet most of the time, and the wifi is good and speedy everywhere else as well.

Overall probably not necessary, but it was a good learning exercise in setting up and managing a network. I also setup a Pi-hole DNS service so I am doing some basic ad-blocking and tracking prevention at a network level, but I’ll write about that later. It’s nice having fast internet all over the house. My nerdy inner child is so happy.

Plan A - Hydroponic Dutch Buckets

Initially I wanted to try out hydroponic gardening. Essentially hydroponic gardening is growing plants without soil, using some other media to hold water and nutrients near the roots of the plants. This can help conserve space, get more nutrients to plants, and allow for growing in places or configurations that wouldn’t be possible with soil.

The simplest (active) hydroponic garden, in my opinion, is a basic dutch bucket system. This consists of a 5-gallon or similar sized bucket, some means of getting water in the top, and a drain near the bottom. Ideally the drain should be 2-3 inches above the bottom of the bucket to allow some water to collect. The soil is commonly replaced with materials like perlite or coco coil. The water is treated with soluble fertilizers to create a nutrient solution. The nutrient solution and be collected and reused or drained to waste. This system is simple because it just involves getting the nutrient solution pumped into the top of the bucket and gravity to collect and reuse the nutrient solution.

Note: There are actually more simple, passive hydroponic systems, but these didn’t scratch the itch of building something enough for me, I had to go more complex.

After reviewing various setups, I decided several dutch buckets would be the way to go. I’d use 5-gallon buckets for the pots, PVC pipe for the drains and collection, a 55-gallon drum for the water reservoir, and a pump + host + dripper irrigation fittings to do the circulation.

I was able to source the 55-gallon drum from Facebook marketplace for $10. I was surprised by how many were listed for free/cheap, they seemed easy enough to find! I found some free scrap wood on Craigslist for street pickup. Initially I planned to get the lumber new but after seeing the prices I opted for a more economical and eco-friendly solution.

I found a fountain pump at Harbor Freight that met my height and flow rate needs. Pumps are typically rated for a certain height relative to the pump AT a certain flow rate. As the pump lifts water higher relative to itself, the flow rate will slow and eventually stop. Be sure that the pump you choose will give you the flow you need and the height you want.

Note: Flow rate is important to consider for some systems like Nutrient Film Technique (NFT) channels, but not for others that don’t run continuously, like flood-and-drain systems.

I planned to construct a short platform to set the buckets on and bury the 55-gallon drum deep enough to allow the solution to drain back into the reservoir. However, I never made it to construction because I was confronted by Plan B.

Plan B - Just use the dirt

After explaining all the benefits of hydroponic gardens and why I wanted to try it, my fiancé made the fair point that it’s rare to have a patch of dirt in Chicago, so why cover the dirt with plastic buckets. This was ultimately the way we decided to go. The point that swayed me was she said she would spend more time outside with me if there was a nice garden. So, dirt garden it was.

I realize I don’t know much about gardening, so I venture to the local library. I haven’t been in a library in so long, it felt nice to feel like a kid in a candy store with books again. I find a few books on local plants and gardening and get checked out. After getting home and reviewing the gardening books. I decided to try and identify what plants I had in the garden and what condition the soil was in.

I used the app iNaturalist to take photos of the plants in the garden and it suggested classifications for them. It was helpful when other locals would comment and confirm or refine one of the AI’s suggestions. I used a few soil tests from the books to assess the dirt. I would grab a fistful of dirt and squeeze and judge it based on how it crumbled as I let go.

After some consideration I decided that mostly the garden was full of weeds and local grasses and the dirt was in okay, but not great condition. I decided I needed to weed the garden and turn the dirt over to get ready for any new plants. This is where the fun and hard work began. I cleared the top layer of dirt and weeds, along with lots of trash and rocks from previous tenants. I also loosened the dirt to get ready for additional soil.

I thought the soil needed more sand, since it seemed to cling together a little too well. I decided to go with some of the cheapest stuff from Lowe’s that still had any nutrient content. I got 10 bags, hopefully enough to add a couple inches across the area I wanted to plant. I got the bags of dirt home and worked them into the existing soil. This was by far the hardest work but also the most enjoyable.

Once I had got the garden ready, we made a trip to a local nursery to get some plants for the space. We went to the Urhausen Greenhouses and found all the plants we could want. We got several varieties of peppers and tomatoes, as well as some cucumber and watermelon, and some Salvia and Marigold flowers. I planted them when we got home, gave everything a good water and have hoped for the best!

Plan B+ - A bonus NFT system

I also had all this free wood and PVC so I decided to construct a four channel NFT setup in the back of the dirt patch. This area doesn’t get a ton of sun anyway so it seemed like a decent gamble on the space. I used the wood to build A-frame supports for the PVC channels and screwed them in place. I buried the 55-gallon drum to be the reservoir and the channels will drain back into the drum. It’s a simple enough setup and hopefully will grow several small plants.

Overall it seems to be growing well and it has made the back space a much more enjoyable place to hang out! We’ve eaten several meals out here and I’ve started hammocking over the plants. I also enjoy fast wi-fi while doing this because of my overkill home network setup, which I will write about soon.

One of these projects I found is the Pwnagotchi.

What is a Pwnagotchi?

Pwnagotchi is a project created in 2019 by evilsocket, designed to resemble a cute little electronic pet, the Tamagotchi, only instead of feeding it cartoon food, you feed it Wi-Fi handshakes. Handshakes, specifically the 4-way handshake, are part of the process Wi-Fi access points and clients use to turn a wi-fi password into the set of cryptographic keys used for communication between devices.

The Pwnagotchi also features a neural network, designed to learn from the environment around it and get better at collecting handshakes over time. From the documentation: “Pwnagotchi is an A2C-based “AI” powered by bettercap and running on a Raspberry Pi Zero W that learns from its surrounding WiFi environment in order to maximize the crackable WPA key material it captures.” This makes it a good project not only for learning about wi-fi security, but also touches on AI and is built in Python, which are two other areas that I have been digging into lately.

So this hacks Wi-Fi networks?

The Pwnagotchi doesn’t hack networks and won’t give you the password for the neighbors wi-fi. While the handshakes that it captures in theory could be used to crack the passwords, doing so would be unethical and is likely illegal in most places. What the Pwnagotchi captures are the encrypted keys that are exchanged to allow secure communication between an access point and client. Using a tool like Hashcat in conjunction with a word-list could in theory provide the password to the network, but again, not a very neighborly thing to do.

The intention of the Pwnagotchi, and many projects like it, is to teach people about wi-fi security and emphasize the importance of selecting a secure password. Something like “password123” might be easy to remember and share with your friends, but it’s also among the most commonly used passwords (1,085th most common to be exact) and almost certainly would appear on the word-list a hacker would use to crack these handshakes and gain access to your network. By making people aware of the tools and techniques used by hackers, everyone can be more aware of their vulnerabilities and implement better security practices overall.

What can you do with these handshakes?

I’m planning to write a more detailed explanation of the differences in wi-fi security protocols, a detailed overview of the handshake process, and go over cracking a password with Hashcat for a test network that I own.

For me, the handshakes represent wi-fi networks that I’ve been around and kept my little Pwnagotchi happy. As I’ve started carrying my Pwnagotchi with me on walks and bike rides, I’ve collected more and more handshakes. It’s fun to see the number go up as I’ve explored more places. It’s almost like Pokemon Go, but somehow nerdier.

oPwngrid

There also exists a network of Pwnagotchis, oPwngrid, created by the maintainers of the project, where you can track stats and see who has collected the most handshakes. The Pwnagotchis can become friends and even be used to send messages between owners. You can find mine on the network here: joeypwns | ( ⚆_⚆)

I named my device “joeypwns” in honor of Joey Chestnut, the famous competitive eater.

Build your own

It’s relatively straightforward to build your own Pwnagotchi. You just need a Raspberry Pi Zero 2 W, an e-ink display, and optionally a battery to take the little guy on the go. I also 3D printed a case to protect everything.

Hardware

• Raspberry Pi Zero 2 W
  • You will also need headers and a way to solder them on
  • Some stores will sell Raspberry Pis with pre-soldered headers, totally worth it in my opinion
  • Some mobile phone repair shops will solder them on for a few bucks
• Waveshare 2.13 inch E-Ink Display
  • MicroCenter sells a knockoff but go for the Waveshare, it will make things much easier
• PiSugar Battery
  • It’s possible to use other power sources or an external battery pack, but the form factor of the PiSugar is perfect
• MicroSD Card
  • UHS-I class or higher is recommended, see more here

If all this seems like too much hassle and you can’t live without a Pwnagotchi, you can buy them pre-assembled with a case here.

Cases

Several options for cases are available here: 3D Printable Cases.

I used this case from gimzmoe on Thingaverse because I liked the clip-loop.

If you don’t have a 3D printer you can purchase a case on Etsy, or ask nicely and I’d probably send you one.

Software

While the original project was created and released by evilsocket, several forks have branched off and continued development. The one with the largest community seems to be Jayofelony’s version here: jayofelony/pwnagotchi

Download the latest release here: releases.

Flash the image to your MicroSD card using a tool such as Balena Etcher or the Raspberry Pi Imager.

Once the flash is complete and you have your hardware assembled, insert the MicroSD into the Raspberry Pi and power it on. It will take a few minutes the first time it boots so be patient, cutting power before setup is complete could corrupt files and require you to re-flash the SD card.

Now you should be up and running! Take your Pwnagotchi out into the wild and see what you can catch!

More detailed instructions exist at pwnagotchi.org for putting your own device together. I would recommend giving the documentation a read as there are several configuration options and cool things you can do that I haven’t covered here.

Let me know if your build your own, I’d love to see what you create! If you have any feedback or questions I would be happy to get in touch via email.

While things are a little more complicated now than simple HTML sites and CI/CD consisting solely of FileZilla, some things, like my hosting budget, stay the same. How much does a Standard_D4_v4 on Azure cost nowadays anyway?

Building and hosting a server at home has been a great way to learn new skills and host some small services on a budget. In this post, I’m detailing my homelab journey, from a single server to a multi-node cluster, as well as the skills I have learned along the way.

Why build a homelab?

I have found building a homelab to be a great way to build relevant IT skills and put things into practice, beyond simply learning the theory. Taking an action oriented approach forces me to consider the real world implications of different technologies rather than only understanding how something is supposed to work, or situations where I might use them.

Building a homelab has also taught me some important lessons, such the importance of reliability when my “users” (my wife) couldn’t access my “services” (turning on our smart lights) or the impact certain choices have on total cost of ownership, eg: my cloud budget and electricity bill.

First Iteration - Starting Small

My first server was a single small form factor Dell OptiPlex PC. These small tower PCs make a great choice for the beginner homelabber as they are small, quiet, energy efficient, and can be found secondhand for under $100, often as low as $50-$60.

While it may seem like a good idea to pick up a rack mounted option like a used Dell PowerEdge or HP ProLiant, consider the size, noise, and power consumption of such a system. These enterprise grade servers are large, loud, and power hungry, potentially costing over $200/year to run 24/7. Not very living room friendly. The skills and concepts apply to small servers just as much as big ones.

Hardware

• Intel Core i5-6500 (4 Cores)
• 8 GB RAM
• 256 GB SSD, 1 TB HDD
• Onboard Intel I219-V 1GbE NIC

Power consumption at idle: 15-20 watts

Network

I connected my single server into my router and assigned it a static IP address on the existing 192.168.x.x subnet. I had some sense and kept the static IP out of the DHCP range, but otherwise had very little networking know-how, which was fine to start out.

Software - VMWare ESXi

I started with a free version of VMWare’s ESXi hypervisor; this let me practice using a similar system to the one I was using at work, without the pressure of breaking anything critical. I never got past a couple VMs, as my hardware wasn’t really cut out for it, but it let me practice the concepts.

Total Costs

• Hardware: $40 on Facebook Marketplace
• Power Consumption: ~$20/year
• Licensing: Free

For under $50 I was up and running, learning new things, and growing my skills rapidly.

Skills Learned

• Choosing the right hardware for the job
• Installing an OS on bare metal
• Working with VMWare ESXi
• Creating and using virtual machines
• Some basic networking, like setting static IPs and avoiding clashes with DHCP

Overall, this first iteration of my homelab was a huge success. I was rapidly building skills and learning new concepts that would help me every day at work. Most importantly, it took me out of theory and into the real world, giving me a practical foundation on which I could continue to build.

Second Iteration - Move to Proxmox, Adding Nodes

I quickly ran into two bottlenecks — my server wasn’t very powerful, and free ESXi has a lot of limitations. This led me to explore other options and discover Proxmox, a free open-source hypervisor based on Debian Linux. It also led to me purchasing another SFF PC to add resources to my homelab.

These additions let me begin to learn about high-availability and implement automatic backups and shared storage. I also began to host useful services such as Joplin for synchronizing my notes and Pihole for network level ad-blocking and DNS.

Skills Learned

• Linux administration, managing Proxmox
• Automatic Backups
• Network File System (NFS) and shared storage
• DNS Filtering

As my homelab continued to grow, I continued to grow and develop my skill set and started to get some personal benefits as well. I had some momentum and felt like this was a platform with which I could scale and grow.

Third Iteration - Clustering

I consider this a third iteration because, well, I broke things pretty thoroughly in the process. Thank God this wasn’t a production system.

I purchased another SFF PC, this time an HP EliteDesk, which gave me a sufficient number of servers to create a Proxmox cluster. This allowed for central management of all servers, easily migrating VMs between servers, and high availability VMs.

Adding the third server also prompted me to reconsider my network. Not only was I using up more IP addresses, I was running out of physical ports, and wanted to be able to separate server network traffic from personal network traffic.

It was during the migration from my 192.168.x.x subnet to a 10.x.x.x subnet that I broke the cluster. This led me down several rabbit holes and I began to learn the intricacies of distributed systems. I was finally able to restore the cluster and not lose any data in the process, gaining a real appreciation for the challenges presented by complex systems.

I added a switch and used VLANs to segment my network, allowing me to control the flow of traffic between devices. It certainly isn’t an enterprise data center, but it gave me a taste of configuring a more complex network, and thinking about the flow of traffic through the system.

All of a sudden, tools like Ansible and Terraform made much more sense. Not just in a theoretical way but in a “I can’t believe I have to update this in so many places” way. I started using automation and Infrastructure-as-Code tools to help me manage everything.

Skills Learned

• Setting up and managing a Proxmox cluster
• High availability VM configuration
• Network segmentation, configuring VLANs
• Subnet design, implementing a new addressing scheme
• Distributed systems, understanding the complexity of multi-node setups
• Data preservation, not losing any information as I managed major system changes
• Using tools like Ansible to make server administration easier

This has been the system on which I have continued to build. It has presented me with several challenges and opportunities. I’m really proud of the homelab I’ve built and the skills I’ve learned along the way. With this server cluster and network configuration I feel like I have something worthy of the title of “homelab”. It has served as my DIY data center and I use it to host several services today.

Final State, for now…

Currently, I still have three nodes in my cluster, plus a Raspberry Pi for backup DNS and VPN access. After a thoughtless reboot where I locked myself out of my network while on vacation, I decided I needed some redundancy for these key functions. I’ve added some RAM, some SSDs, and a networking card for a future OpnSense project, but the bones are the same.

Physical Servers:

• Dell OptiPlex 7050 SFF: i7-7700, 8 cores, 16 GB RAM
• Dell OptiPlex 5040 SFF: i5-6600, 4 cores, 16 GB RAM
• HP EliteDesk 800 G2 SFF: i5-6500, 4 cores, 8 GB RAM
• Raspberry Pi 4 8 GB

Network:

• Layer 3: TP-Link ER605
• Layer 2: TP-Link TL-SG105
• APs: Netgear Orbi Pro WiFi 6 SXR/S30 in AP mode

VLANs:

• Personal: PCs, phones, tablets, Apple TV
• Servers: Proxmox nodes, VMs
• IoT Devices: Light bulbs, smart plugs, ESP32s
• Sus: Sketchy IoT devices, anything untrusted
• Guest: Guest Wi-fi

Total Costs

Hardware

• $220 - SFF PCs
• $40 - SSDs: 1 TB from MicroCenter, 1 TB for Christmas (Thanks Mom and Dad!)
• $40 - Intel I350-T2 Dual Port 1GbE Card for OpnSense
• $75 - Router/Switch - not including APs
• $75 - Raspberry Pi

Total Hardware Cost: $450

Electricity

I would estimate the total consumption to average around 90 watts, incl.

90 Watts / 1000 W/kW x 24 hours/day x $0.1621/kWh * 365 days = $127.79

Total Electricity Cost: ~$130/year

All in for 3 years of Homelabbing: $831

If you’re reading this and thinking this might benefit you, I highly encourage you to take the leap. I started with a single Dell SFF PC purchased secondhand for $40. Generally I have taken the “do more with less” approach in an attempt to save money and get creative with solutions. While it’s the dream of many an IT professional to have a full rack in their closet, starting where you can is far better than not starting at all.

If you have any feedback or input I would be happy to get in touch via email. Let me know what you would do different or ask any questions about getting started!

Contents

1. Part One: Public/Private Keys
2. Part Two: Certificates
3. Part Three: Tools for Working with Certificates

Windows and Java File Types

Windows and Java platforms utilize different file formats to store and manage TLS certificates. Understanding these file types is essential for proper certificate handling, installation, and configuration in various applications and systems. The following are some common file formats used for TLS certificates on Windows and Java platforms:

1. Personal Information Exchange (PFX) or PKCS#12:

Windows systems often use the .pfx file format to store a certificate and its corresponding private key in a single, password-protected file. This format is useful for importing and exporting certificates with their associated private keys, simplifying certificate deployment and management. The PKCS#12 standard defines the .pfx file format, and these files are often used in Microsoft products, such as IIS and Exchange Server.

2. DER (Distinguished Encoding Rules):

Both Windows and Java platforms can use the .der file format, which is a binary encoding of a certificate. DER files typically contain only a single certificate without its associated private key. These files can be used for various purposes, such as installing root and intermediate certificates into the trusted certificate store.

3. PEM (Privacy-Enhanced Mail):

The .pem file format is a widely-used format for storing certificates and keys in plain-text, base64-encoded form. PEM files can include certificates, private keys, or both, and can be used across different platforms, including Windows and Java. They are often utilized in open-source applications, such as OpenSSL and Apache HTTP Server.

4. Java KeyStore (JKS):

Java applications use the Java KeyStore format to store certificates, private keys, and other cryptographic materials in a single, password-protected file. The .jks file format is specific to Java and is used by default in Java applications for managing keys and certificates. Java KeyStores can hold multiple entries, allowing for the storage of several certificates and keys in a single file.

5. Java TrustStore:

Similar to the Java KeyStore, the Java TrustStore is used to store trusted certificate authorities’ certificates. It is often used to store root and intermediate certificates that establish a chain of trust for validating end entity certificates. TrustStores use the same .jks file format as Java KeyStores but serve a distinct purpose in the certificate management process.

A note on encoding

When working with certificates, you’ll encounter two primary encoding methods: DER (Distinguished Encoding Rules) and PEM (Privacy-Enhanced Mail). Understanding these encoding methods is crucial for handling and managing certificates effectively.

DER (Distinguished Encoding Rules): DER is a binary encoding method used for certificates, keys, and other cryptographic data. It is a strict, compact, and unambiguous representation based on the ASN.1 (Abstract Syntax Notation One) standard. DER-encoded files are typically smaller than their PEM counterparts and are often used in situations where space and performance are critical. DER files usually have extensions like .der, .cer, or .crt.

PEM (Privacy-Enhanced Mail): PEM is a text-based encoding method that uses base64 encoding to represent binary data as ASCII text. PEM-encoded files include a header and footer to mark the beginning and end of the certificate or key data. This format is widely used across different platforms and applications due to its human-readable nature and compatibility with various tools. PEM files typically have extensions like .pem, .crt, .cer, or .key.

In summary, DER and PEM are the two primary encoding methods used for certificates and cryptographic data. DER is a compact binary format, while PEM is a more human-readable text-based format. Understanding these encoding methods will help you manage and work with certificates effectively across various platforms and applications.

Guide to File Types

• .pem (Privacy-Enhanced Mail): A text-based, base64-encoded file used for storing certificates, private keys, or both; compatible with various platforms and applications.

• .crt (Certificate): A file format used for storing certificates, which can be either DER-encoded (binary) or PEM-encoded (base64 text); primarily associated with public key certificates.

• .cer (Certificate): Similar to .crt, a file format used for storing certificates, which can be either DER-encoded (binary) or PEM-encoded (base64 text).

• .der (Distinguished Encoding Rules): A binary-encoded file format used for storing certificates and other cryptographic data; compact and unambiguous representation based on ASN.1 standard.

• .key (Key): A file format used for storing private keys, typically in PEM-encoded (base64 text) format.

• .pfx (Personal Information Exchange) or .p12 (PKCS#12): A binary file format used for storing a certificate and its associated private key in a single, password-protected file; commonly used on Windows systems for importing and exporting - certificates and keys.

• .jks (Java KeyStore): A binary file format used by Java applications for storing certificates, private keys, and other cryptographic materials in a single, password-protected file.

• .csr (Certificate Signing Request): A file format used for sending a public key and identifying information to a Certificate Authority (CA) to request a signed certificate.

• .crl (Certificate Revocation List): A file format used for listing revoked certificates, typically published and maintained by Certificate Authorities (CAs).

These file types are commonly used for managing and configuring certificates and cryptographic data across various systems, platforms, and applications.

Tools for working with certificates

OpenSSL

OpenSSL is a widely-used, open-source toolkit that implements the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols, as well as a robust cryptography library. It provides a versatile command-line interface for creating, managing, and converting certificates, keys, and other cryptographic data. OpenSSL supports a variety of operations, such as generating certificate signing requests (CSRs), signing certificates, creating and managing private keys, and validating certificate chains.

While OpenSSL can be really useful, using a command line tool can be intimidating when first starting out.

The OpenSSL source code can be downloaded here: OpenSSL Source Downloads

Probably more practical for most folks will be the Windows installer made available by Shining Light Productions here: Windows OpenSSL Installer

Java Keytool

Java Keytool is a command-line utility bundled with the Java Development Kit (JDK) and Java Runtime Environment (JRE) for managing key pairs, certificates, and keystores. It supports operations such as creating and importing certificates, generating key pairs, exporting certificates, and listing the contents of a keystore. Java Keytool is particularly useful for managing certificates in Java-based applications and environments.

CertMgr

CertMgr is a Microsoft Windows command-line utility for managing certificates in the Windows Certificate Store. It allows users to perform various tasks, such as adding, deleting, or viewing certificates, as well as managing certificate revocation lists (CRLs) and certificate trust lists (CTLs). CertMgr is a convenient tool for Windows administrators and developers who need to manage certificates on their local machines or in a Windows-based environment.

KeyStore Explorer

KeyStore Explorer is a free, open-source, graphical tool for managing Java keystores and PKCS #12 files. It provides a user-friendly interface for creating, importing, and exporting certificates, as well as generating key pairs and converting between different keystore formats. KeyStore Explorer supports various operations, including signing and verifying certificates, editing certificate properties, and examining certificate chains. This tool is particularly useful for users who prefer a graphical interface over command-line utilities for managing certificates and cryptographic data.

KeyStore Explorer can be downloaded here: KeyStore Explorer

Common Issues and How to fix them

Warning for Self-Signed Certificates

A warning for self-signed certificates might appear because self-signed certificates lack the endorsement of a trusted Certificate Authority (CA). A CA acts as an independent, trusted third party that verifies the identity of a certificate owner. When a certificate is self-signed, the issuer and the subject of the certificate are the same entity, meaning the certificate owner is vouching for their own identity. This raises concerns about the authenticity and integrity of the certificate, as there is no external validation from a trusted CA.

Often, browsers will let you continue with a self-signed certificate, but will show the connection as Not Secure and have a red warning where the lock icon would be in the address bar. Some browsers and devices, such as iPads and iPhones, will not access sites with self-signed certificates at all without additional configuration.

To eliminate the warning for a self-signed certificate, you can add the certificate to the Trusted Root Certificates store on Windows. This action tells the system to trust the certificate, effectively treating it as if it were issued by a trusted CA. Here’s how to add a self-signed certificate to the Trusted Root Certificates store:

1. Locate the self-signed certificate file (usually in .cer or .crt format).

2. Double-click the certificate file to open the Certificate dialog box.

3. Click on the “Install Certificate” button to launch the Certificate Import Wizard.

4. Select “Local Machine” as the store location and click “Next.”

5. Choose “Place all certificates in the following store” and click “Browse.”

6. In the “Select Certificate Store” dialog, select “Trusted Root Certification Authorities” and click “OK.”

7. Click “Next” and then “Finish” to complete the import process.

After completing these steps, the self-signed certificate will be added to the Trusted Root Certificates store on your Windows machine, and the warning should no longer appear when accessing the resource secured by the certificate. Keep in mind that this process should be done cautiously, as adding a self-signed certificate to the Trusted Root store may expose the system to security risks if the certificate owner is not trustworthy.

I only recommend this solution for demonstration systems or development environments. For any production use case you should get a real certificate issued by a trusted CA. Nowadays, this can be done easily, often automatically, and free with tools from Let’s Encrypt. In future articles, I will go over setting up a reverse proxy like Traefik to handle all of this automatically for you, eliminating a lot of the hassle of dealing with certificates.

Expired Certificate

1. KeyStore Explorer is a graphical tool for managing Java keystores and cryptographic data. To create a new self-signed certificate using KeyStore Explorer, follow these steps:

2. Download and install KeyStore Explorer from the official website (http://keystore-explorer.org/) if you haven’t done so already.

3. Launch KeyStore Explorer.

4. In the main menu, click on “Create a new KeyStore.” Select the type of KeyStore you want to create (e.g., JKS, PKCS #12, BKS, UBER, etc.). For most purposes, JKS (Java KeyStore) is a common choice.

5. Once the new KeyStore is created, right-click on the empty space in the main window and select “Generate Key Pair.”

6. Choose the key pair algorithm (e.g., RSA, DSA, EC) and the key size (e.g., 2048 bits for RSA), then click “OK.”

7. In the “Generate Key Pair - Enter Details” window, fill in the required information for the new self-signed certificate. This information typically includes fields such as Common Name (CN), Organization (O), Organizational Unit (OU), Locality (L), State (ST), and Country (C). Make sure to enter the correct information, as it will be used to identify the certificate owner.

8. Set the validity period for the certificate (usually specified in days). A longer validity period is generally more convenient but may pose security risks if the private key is compromised. Click “OK” to proceed.

9. Enter an alias for the key pair entry in the KeyStore. This is a unique identifier for the key pair and certificate within the KeyStore. Click “OK.”

10. You’ll be prompted to set a password for the key pair entry. Enter a strong password and click “OK.”

11. The new self-signed certificate and its corresponding key pair are now created and added to the KeyStore. You can view the details of the certificate by double-clicking on the entry.

12. To save the KeyStore, go to the main menu and click “File” > “Save KeyStore.” Choose the location to save the KeyStore file and set a password to protect its contents.

With these steps, you have successfully created a new self-signed certificate using KeyStore Explorer. Remember that self-signed certificates might cause trust warnings in browsers and other applications, as they lack a trusted Certificate Authority’s endorsement.

Again, this solution should only be done for demonstration systems or development environments. For any production use case you should get a real certificate issued by a trusted CA. Nowadays, this can be done easily, often automatically, and free with tools from Let’s Encrypt.

CN Mismatch

A Common Name (CN) mismatch error occurs when the domain name in a website’s SSL/TLS certificate does not match the domain name in the browser’s address bar. To fix a CN name mismatch error, follow these steps:

Verify the domain name: Double-check the domain name in the browser’s address bar and ensure it matches the domain name specified in the SSL/TLS certificate. If there’s a typo or mistake in the address, correct it and reload the page.

Check for Subject Alternative Names (SANs): If you expect the certificate to work for multiple domain names, ensure that all necessary domain names are listed as SANs in the certificate. If they are missing, you’ll need to reissue the certificate and include the missing domain names as SANs.

Reissue the certificate: If the domain name in the certificate is incorrect, you’ll need to obtain a new SSL/TLS certificate for the correct domain name. Contact your Certificate Authority (CA) to reissue the certificate with the correct CN, or create a new Certificate Signing Request (CSR) with the correct CN and submit it to the CA.

Install the corrected certificate: Once you have the new certificate with the correct CN or updated SANs, install it on your web server according to the server’s documentation. Make sure to replace the old certificate with the new one, and ensure the server is properly configured to use the updated certificate.

Test the connection: After installing the new certificate, clear your browser’s cache, and restart the browser. Navigate to your website using the correct domain name, and check if the CN mismatch error is resolved.

By following these steps, you should be able to fix a CN name mismatch error and ensure secure communication between the website and its visitors.

This concludes the SSL/TLS guide, I hope it will be a good resource for anyone looking to better understand this fundamental part of security that is found nearly everywhere nowadays. I know writing this guide really helped solidify the concpets and has helped me in professioanl and personal projects alike.

If you found this helpful feel free to buy me a coffee, and if you have any feedback or corrections I would be happy to get in touch via email.

Thanks for reading!

Contents

1. Part One: Public/Private Keys
2. Part Two: Certificates
3. Part Three: Tools for Working with Certificates

Certificates

This is where our public keys become certificates. Certificates are how clients verify servers are who they claim to be. Certificates provide this verification by including a signed message from a trusted company, known as a Certificate Authority (CA), who verifies the domain name and company information listed on the certificate is correct and true.

A certificate is obtained from a Certificate Authority by first creating a keypair, then sending the public key along with all the information associated with the owner of the public key. The combination of public key and identifying information is called a Certificate Signing Request (CSR) and is the file (.csr) sent to the CA to request a certificate. The signed certificate is then sent back, which includes the public key and identifying information of the requestor, but also the signature of the CA verifying the validity of the information.

Common Name and SAN Name

One of the fields for information is the Common Name (CN) which refers to the fully qualified domain name (FQDN) for the server. The FQDN simply refers to the complete URL without any protocol or port information. For example: alanabbott.me, mail.google.com, or pmox-node01. It is important to match the FQDN to the address you will use to reach the server, as the browser will use this to verify the certificate is valid.

If a server needs to be reached from multiple addresses a Subject Alternate Name (SAN) can be specified which provides alternate names from which the server can reached.

The other information fields should be completed if sending a CSR to a CA but otherwise don’t matter.

Types of Certificates

There are three types of certificates to be aware of:

Root Certificate

This is used by the CA to sign either intermediate or end entity certificates. Typically have very long expiration dates. These are what make up the Trusted Root Certificate Authorities.

Intermediate Certificate

This is a certificate that has been signed by a root certificate, but may be used to sign more certificates. Can sign either end entity certificates or other intermediate certificates. Shorter expiration dates and rotated more often.

End Entity Certificate

These are certificates assigned to individual servers. They can not be used to sign more certificates.

It’s good to know that individual certificates can also have restrictions placed on what they can be used for when they are created, which can sometimes cause headaches.

Certificate Chains

A certificate chain is a series of certificates that originate from a trusted root certificate and extend through any number of intermediate certificates, ultimately leading to the end entity certificate. The purpose of a certificate chain is to establish a chain of trust from the end entity certificate back to the root certificate, verifying the identity and authenticity of the server or client involved in the communication.

The process of validating a certificate chain involves verifying the digital signatures of each certificate in the chain, starting with the end entity certificate and moving up the chain towards the root certificate. Each certificate in the chain is signed by the issuing authority of the next certificate in the chain. The chain is considered valid if the root certificate is found in the client’s trusted root certificate store.

In summary, a certificate chain consists of:

• End Entity Certificate - assigned to the server or client that needs to be authenticated.
• Intermediate Certificates (if any) - signed by the root or another intermediate certificate and used to sign end entity certificates.
• Root Certificate - the top-level certificate, trusted by clients and used to sign intermediate certificates.

Certificate Bundles

A certificate bundle is a collection of multiple certificates combined into a single file. Bundles are used to simplify certificate management and distribution, particularly when dealing with certificate chains or multiple certificates for different domains or services. Bundles can be provided in various file formats, such as .pem, .pfx, or .crt, depending on the platform and application requirements.

Expiration Dates

Both CA signed and self-signed certificates have an expiration date, requiring companies to confirm they still control the domain name and private key associated with the certificate every so often. In production it is good practice to set expiration dates conservatively and rotate certificates often. In a demo environment, I usually set them for as long as I expect the demo to live. If a company loses control of a production private key, they should get new certificates immediately, as they could be impersonated by anyone with the private key.

Self-Signed Certificates

A self-signed certificate is represented by one of the above scenarios, where we must accept Person A’s identity because they say so. A self-signed certificate provides a public key without a signed message verifying the identity of the key holder. Browsers by default show an error and don’t visit sites with self-signed certificates, for good reason, I don’t want anyone claiming to be my bank without signed verification.

To bypass this, we can add our self-signed certificate to the Trusted Root Certificate Authorities. Most operating systems have a default group of Trusted Root Certificate Authorities. Java has a separate group of default trusted CAs, known as cacerts. By adding our self-signed certificate to the Trusted Root CAs group, browsers will recognize our self-signed certificate and will not show errors, provided our certificate isn’t expired and matches the FQDN used to reach the server.

Self-Signed Certificate Authority

If you need to generate certificates for several servers, you can create a self-signed Certificate Authority, which can then be used to sign multiple certificates for all of the servers, while only requiring the self-signed CA to be added to the Trusted Root Certificate Authorities.

Getting CA Signed Certificates for Free

Services such as Let’s Encrypt, a free certificate authority created and run by the Internet Security Research Group (ISRG), have made getting certificates significantly easier. Their work as made implementing TLS much simpler and helped proliferate secure HTTPS as the default in most places. I plan to write more about using Let’s Encrypt in the future, and integrating with tools like Traefik, but for now check out their Getting Started page.

Continue reading Part Three to learn about some common tools used for working with certificates, or go back to Part One to learn about public / private keys as the foundation for X.509 certificates.

If you found this helpful feel free to buy me a coffee, and if you have any feedback or corrections I would be happy to get in touch via email.

Managing TLS and certificates can be a huge pain as well, especially in environments that can go long stretches between use and be shared by many users. We’re probably all too familiar with the security warnings about certificate errors, either showing as insecure or worse, not loading at all.

In this guide, I will break down the pieces that come together to form the TLS protocol and go over some tips for working with certificates. Understanding the basics helps make sense of errors and makes the whole ordeal a little less daunting.

Contents

1. Part One: Public/Private Keys
2. Part Two: Certificates
3. Part Three: Tools for Working with Certificates

A precursor: Identity, Privacy, Trust, and Security

If two people want to send messages to each other they can pass notes using a messenger. This would not be very private however, because the messenger could easily read a message before delivering it. It would also not be very secure because the messenger could alter the message before delivery. There is no way to ensure or trust that the message is really from the sender or that it hasn’t been changed. The identity of the sender can’t be verified by the recipient.

The two people could implement a code, where they shift A to B, C to D, and so on. However, this would require them to agree upon this code via an outside channel. It would not be possible to establish trusted communication without meeting in person, or using an existing outside channel. This is sometimes referred to as a shared secret.

If two people need to exchange information securely without meeting previously, such as webservers and a new client, they can use public and private keys to accomplish this. The use of public and private keys has many advantages, such as private communication without a shared secret, as well as verifying identity and providing trust through things like signatures and certificate chains.

It helped me to understand the various pieces of TLS certificates when I broke out the ideas of privacy, identity, and trust.

• Privacy - Communication between parties can’t be read by outside listeners
• Identity - Can you verify who sent you that message and that it wasn’t modified?
• Trust - Can I verify that you are who you say you are?

In my mind, these are the core concepts behind “secure” communication. When we say we have a secure connection to a server or device, we mean we can verify the identity of the sender, the integrity of the message, and not worry that 3rd parties can read what we’re sending. Hopefully by the end of this guide you will feel comfortable with the way TLS certificates provide privacy, identity, and trust which will make using them, and fixing them, much easier.

Public Keys and Private Keys

The most important concept in the TLS protocol is public keys and private keys, which make up public key infrastructure (PKI). In reality these keys are just very, very large numbers used in cryptography algorithms, stored in certain specific formats. These keys enable everything in TLS with two functions.

Two important functions:

• Messages encrypted with the public key can only be decrypted with the private key
• Messages encrypted with the private key can only be decrypted with the public key

If Person A wants to send a message to Person B, they would each generate a keypair (public and private key) and exchange public keys, keeping their private keys secret. It doesn’t matter if the public keys are intercepted, as they are public information and only represent the identity of the private key holder.

The process for conversation would be as follows:

1. For Person A to send a message to Person B, they would use Person B’s public key to encrypt the message

2. Person B would use their secret private key to decrypt the message, only readable to them

To respond:

1. When Person B sends a message to Person A, they would use Person A’s public key to encrypt the message

2. Person A would use their secret private key to decrypt the message, only readable to them

This system is great for ensuring privacy, as only the intended recipient can decrypt and read the message. It is not, however, a great system for verifying identity and providing trust. We must talk about signing and verification to understand the other side of public key infrastructure.

Remember, private keys can also encrypt messages that can only be decrypted by the public key, and the public key is widely available and tied to the key holder’s identity. To verify their identity, the private key holder can use their secret key to encrypt a message, only decryptable by their public key. This process is known as signing the message.

When the recipient gets that message, they will use the sender’s public key to confirm they are the one who encrypted it, in a process called verification. Because the public key is tied to the identity of the private key holder, the recipient can be certain the message is from the sender and hasn’t been changed in transit.

The process for signing a message would be as follows:

1. Person A uses their private key to encrypt a message, and sends it to Person B

2. Person B uses Person A’s public key to decrypt the message, confirming it is from Person A

The process for verifying a message:

1. Person B receives an encrypted message from Person A, who claims to have signed it using their private key

2. Person B successfully decrypts the message using Person A’s public key, confirming it was sent by Person A

This system may seem to check all of our boxes, allowing for two-way, private communication where the identity and integrity of each message can be verified. However, we are required to trust that Person A and Person B are who they claim to be. How can we be sure it is indeed Person A and Person B who hold those private keys? If we had a signed message from someone we trusted, we could verify that Person A’s public key (and private key) belong to them.

Cryptography Nerd Moment

The above system roughly represents PGP (Pretty Good Privacy) which has been around for over 30 years and is pretty much the standard for encrypting or verifying communications. Beyond just messaging, PGP can be used to sign and verify blocks of code or even entire pieces of software. A developer can sign a package, and provide the signature. Using their public key and cryptography software, you can verify that the program is not corrupted, either accidentally or maliciously.

A limit of PGP is that it relies on a “web of trust” where individuals will endorse each other’s public keys, confirming they belong to the claimed owner. While this decentralized model may work well in some situations, a system was needed for a more streamlined method of trust management, leading to X.509 certificates, which are described in the Part Two of this guide.

There are several algorithms that can be used to generate the key pairs, such as RSA or IDEA, but they all use incredibly large numbers and mathematical processes that would be practically impossible to undo using modern computers. A description of the math behind creating keys can be found here: RSA (cryptosystem) - Wikipedia

There is the possibility that quantum computers could very quickly break the encryption used in PGP and TLS communication. This would mean that virtually all information encrypted in the last 30 years could be decrypted and read. It’s speculated that some people may collect encrypted information with the hope of decrypting it in the future using quantum algorithms. In light of this, work is being spent developing new cryptography algorithms, that rely on different principles and would make them resistant to future decryption using quantum computing.

Continue reading Part Two to learn about how X.509 certificates enable TLS communication and keep the modern internet secure.

If you found this helpful feel free to buy me a coffee, and if you have any feedback or corrections I would be happy to get in touch via email.