DEV Community: Tarique Mehmood

PKI With No Headache (Part 3): Bits, Bytes, and Trust

Tarique Mehmood — Wed, 06 Aug 2025 10:54:56 +0000

When PKI Becomes a Black Box

In everyday use, PKI often gets boiled down to “keys and certificates.” Most professionals know how to generate a key pair, install a certificate, or glance over a few standards. Tools make the process easy — and most documentation stops there, because going deeper is hard to explain.

But that surface knowledge only works until something breaks.

When a certificate suddenly stops working, it's like hitting a wall. Without understanding how a certificate is built — its structure, encoding, and validation rules — troubleshooting becomes guesswork. And that’s when the real headache begins.

Who Cares About ASN.1 and DER?

Ever wondered how PKI manages to organize sensitive data — like keys, signatures, and certificates — into a single file that can be saved, transmitted, and interpreted with bit-level precision?

That’s where ASN.1 and DER come in — two of the most overlooked yet critical foundations of PKI. Every time you generate a key, sign a certificate, or exchange cryptographic data, ASN.1 defines the structure, and DER ensures it’s encoded in a precise, unambiguous way. They work silently in the background, making interoperability between systems possible.

Put simply: ASN.1 defines what goes in — the object’s type, order, and validation rules. DER defines how it’s packed — the exact byte layout that guarantees the object can be reconstructed with no ambiguity.

RFC 5280 Section 4.1

Below is an excerpt from Section 4.1 of RFC 5280, which defines the basic structure of an X.509 v3 certificate:

4.1.  Basic Certificate Fields

   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

A certificate contains three main components:

tbsCertificate — short for To Be Signed Certificate. This section holds all the meaningful fields (issuer, subject, validity, public key, extensions) and is the exact portion that gets hashed and signed.
signatureAlgorithm — specifies the cryptographic algorithm used to sign the certificate, such as SHA-256 with RSA. It also appears inside the tbsCertificate, so mismatches here can cause verification failures.
signatureValue — the digital signature generated by the CA. It's an encrypted hash of the tbsCertificate, verifiable using the CA’s public key.

Here’s the definition of TBSCertificate, also from RFC 5280:

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
}

This syntax, taken directly from the RFC, shows how PKI uses ASN.1 to precisely structure certificate data — and how every field in your certificate file has a defined place and rule.

Briefly, What is DER?

DER (Distinguished Encoding Rules) is a binary encoding format that faithfully preserves the hierarchical structure of ASN.1 by using a TLV (Tag-Length-Value) format for every field.

Tag indicates the data type of the value and whether it's a container (like a folder) or a leaf (like a file).
Length specifies how many bytes follow.
Value holds the actual content — or in the case of containers, it holds nested TLV-encoded fields.

Together, the Tag and Length form a header that precedes every value. The size of this header is variable (typically 2 to 4 bytes) depending on the data being described. This flexible header system is what allows DER to precisely maintain ASN.1’s tree structure, making it easy to convert between binary and structured ASN.1 representation.

Because DER is a binary format, you can inspect it using a hex viewer. I’m using the xxd command on Linux to view the web-server-der.crt file, which I created in the previous post of this blog series. This file will appear frequently throughout this article.

As described earlier, an X.509 certificate consists of three main components: TBS (To Be Signed), Signature Algorithm, and Signature Value. In the hex output below, I’ve included the full stream so you can see how each component starts with its own DER header (Tag + Length).

$ xxd -p web-server-der.crt 
308202ac[ *1* ]30820194a0030201020214460d9cb0fd270f6e34f2b5c360c8b0
6fd47723b9300d06092a864886f70d01010b05003021311f301d06035504
030c16504b49574e4820496e7465726d656469617465204341301e170d32
35303830323136353932355a170d3237313130353136353932355a301a31
18301606035504030c0f7777772e6578616d706c652e636f6d3059301306
072a8648ce3d020106082a8648ce3d03010703420004f24ca98d334111f1
92d9dea71c0c2427f8141ba5516d8f58429969b4397f5e017ed56cd0e5b5
af1e079eaefd742cfd9128b38b9f32591e24c7b8b402af7d64caa381ad30
81aa300b0603551d0f0404030205a030130603551d25040c300a06082b06
01050507030130270603551d110420301e820f7777772e6578616d706c65
2e636f6d820b6578616d706c652e636f6d301d0603551d0e041604148fad
262431aa214fecf56740cf90f7634e66350a303e0603551d2304373035a1
1da41b30193117301506035504030c0e504b49574e4820526f6f74204341
8214445c36cc2042eb221b919df5bc9498d00f0cf583[ *2* ]300d06092a864886
f70d01010b0500[ *3* ]03820101002b917255013ea0192fae02fa2b5f0be93862
e1b1320e32af601ec8c709e3b6ee016d4a2fa65a5f505053732c0e0d3e46
12ce32ea0b3b303a0b1c9dd3d6a9d2b67d856adc08db8a8eb4ec66806d79
9503cd52fb36f797b139be01d3fb5fb2803668104adbd3e4d2a4ef1f90ca
f8a05575979706ba7dd484a61fbfc180321636296a76cf1fd365ad1b187f
ab1a8d202a7030c0268a05554630f8a3831fd968b62ad472f428e38be216
13572fb3b5f9009a6e8d5579632750780f3e91bbc614f3566106fa3f3e2e
f6077953875fabbe8bbafdb48e58768c5698c5beb9479b705aafbca89271
e820032a739eafdb0c5fc9063569220cf3920b0d185503f33935b996

# 1. TBS Certificate (SEQUENCE)
# Offset: 4
# Length: 0x0194 = 404 bytes

# 2. Signature Algorithm (SEQUENCE)
# Offset: 412 (0x019c)
# Length: 13 bytes (0x0d)

# 3. Signature Value (BIT STRING)
# Offset: 427 (0x01ab)
# Length: 0x0101 = 257 bytes

Back to the ASN.1

You might be wondering: Why bring ASN.1 back into the picture? It already structured the certificate data, and DER encoded it — so isn’t its job done? Surprisingly, no — and this is where ASN.1 really shines.

DER is so precise that we can reverse it back to exactly the same ASN.1 hierarchy, field by field. That’s the power of the TLV structure — it’s fully self-describing.

Try the following commands to convert a certificate back into ASN.1 format:

# For PEM-formatted certificates
openssl asn1parse -in cert-name.crt -i -dump

# For DER-formatted certificates
openssl asn1parse -in cert-name.crt -inform DER -i -dump

For example, parsing a DER-formatted certificate:

$ openssl asn1parse -in web-server-der.crt -inform DER -i -dump
    0:d=0  hl=4 l= 684 cons: SEQUENCE          
    4:d=1  hl=4 l= 404 cons:  SEQUENCE          
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim:    INTEGER           :02
   13:d=2  hl=2 l=  20 prim:   INTEGER           :460D9CB0FD270F6E34F2B5C360C8B06FD47723B9
   35:d=2  hl=2 l=  13 cons:   SEQUENCE          
   37:d=3  hl=2 l=   9 prim:    OBJECT            :sha256WithRSAEncryption
  # output truncated for brevity

You just saw how we used OpenSSL’s most underrated utility — asn1parse — to decode a DER-formatted certificate and reveal its hierarchical ASN.1 structure.

Here’s a brief explanation of the output:

offset — shows the byte position in the file where each TLV block starts
hl — header length (Tag + Length)
d — depth in the nested structure
l — value length
cons / prim — whether the value is a container (like a folder) or a primitive (like a file)
-dump — reveals the actual value for each field

This tree-like output is what makes ASN.1 + DER so powerful — not just for encoding, but also for inspecting and verifying.

Manually Verifying a Certificate Signature

Now we’re about to do something you almost never see in blog posts — not even in documentation or tutorials. We're going to extract the tbsCertificate and signatureValue fields from an actual certificate and manually verify its digital signature using only basic Linux tools.

No OpenSSL shortcuts. No verify command. Just raw data, hashing, and decryption — the way cryptographic verification actually works under the hood.

In Part 1, we created an Intermediate CA.

In Part 2, that CA issued a certificate to a web server.

Now in this post, you should already have the following files ready:

inter.key — the private RSA key of the Intermediate CA (we’ll extract the public key from it)
web-server-der.crt — the DER-encoded X.509 certificate that we’re going to verify

Step 1: Extract `tbsCertificate`

We’ll use asn1parse to inspect the raw structure of the certificate and locate the TBS section. Since it is a top-level field in the certificate structure, we can limit the output to a single depth using grep d=1.

$ openssl asn1parse -inform DER -in web-server-der.crt | grep d=1
    4:d=1  hl=4 l= 404 cons: SEQUENCE          
  412:d=1  hl=2 l=  13 cons: SEQUENCE          
  427:d=1  hl=4 l= 257 prim: BIT STRING

The first line corresponds to the tbsCertificate, which starts at offset 4:

hl=4 → the header (Tag + Length) is 4 bytes long
l=404 → the value is 404 bytes

So, to extract the full tbsCertificate, we need a total of 4 + 404 = 408 bytes — starting at byte offset 4.

This isn’t just a guess — it’s backed by the RFC:

#### RFC 5280 §4.1 – Basic Certificate Fields

> For signature calculation, the data that is to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].

Now that we know the tbsCertificate starts at offset 4 and spans 408 bytes (including its DER header), we can extract it from the certificate using the dd command and save it to a file named tbs-cert.bin.

dd if=web-server-der.crt of=tbs-cert.bin bs=1 skip=4 count=408 status=none

If the extraction was successful, you should be able to view the result with asn1parse:

openssl asn1parse -inform DER -in tbs-cert.bin

Step 2: Extract `signatureValue`

Repeat the same step — but this time, our target is the third line of the parsed certificate:

$ openssl asn1parse -inform DER -in web-server-der.crt | grep d=1
    4:d=1  hl=4 l= 404 cons: SEQUENCE          
  412:d=1  hl=2 l=  13 cons: SEQUENCE          
  427:d=1  hl=4 l= 257 prim: BIT STRING

At first glance, you might assume we should extract from offset 427 and grab 4 + 257 = 261 bytes — just like we did for the tbsCertificate. But that would be incorrect.

This time, we're interested in the raw signature only, without the DER header.

So, should we start at 427 + 4 = 431? Still no — because BIT STRING fields in DER encoding include an extra padding byte right after the header. In most X.509 certificates, that byte is 00, and it's not part of the actual signature.

So we need to skip:

the 4-byte header
and the 1-byte padding

That brings us to offset 432, which is where the actual signature starts. Here’s the command to extract the 256-byte signature and save it to a file:

dd if=web-server-der.crt of=signature.bin bs=1 skip=432 count=256 status=none

If successful, signature.bin will contain the raw signature that was generated by the issuing CA — and we’ll use this in the next step to manually verify it.

Step 3: Decrypt the CA’s Signature

We have inter.key, the private RSA key of the issuing CA. Of course, a CA never shares its private key — so we’ll symbolically extract the public key from it, assuming that’s the only part we’d have in a real-world scenario:

openssl rsa -in inter.key -pubout -out inter-pub.key

Next, we’ll decrypt the signature using the issuer’s public key:

openssl pkeyutl -verifyrecover -in signature.bin -pubin -inkey inter-pub.key -out decrypted-digestinfo.bin

This command produces a file named decrypted-digestinfo.bin, which contains the ASN.1 DigestInfo structure. To inspect it, run:

 $ openssl asn1parse -in decrypted-digestinfo.bin -inform DER
    0:d=0  hl=2 l=  49 cons: SEQUENCE          
    2:d=1  hl=2 l=  13 cons: SEQUENCE          
    4:d=2  hl=2 l=   9 prim: OBJECT            :sha256
   15:d=2  hl=2 l=   0 prim: NULL              
   17:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:3F91773C7CAB65B00412E28E3CDCD89A5D393FE3A41E732087259D92FCC7F42C

At this point, you've successfully decrypted the CA's digital signature and revealed the hash value it was protecting. In the next step, we'll independently hash the tbsCertificate and compare the two values.

Step 4: Calculate the Hash of the TBS Part

Now hash the contents of tbs-cert.bin using the expected digest algorithm — in this case, SHA-256:

$ openssl dgst -sha256 tbs-cert.bin
SHA2-256(tbs-cert.bin)= 3f91773c7cab65b00412e28e3cdcd89a5d393fe3a41e732087259d92fcc7f42c

In my case, the computed hash

3f91773c7cab65b00412e28e3cdcd89a5d393fe3a41e732087259d92fcc7f42c

exactly matches the hash we extracted from the decrypted signature in the previous step.

That’s it — you’ve just completed a manual end-to-end X.509 signature verification using raw bytes, OpenSSL, and no black-box tooling.

This is how you go from “I trust certificates because everyone does” to “I’ve verified it myself, byte for byte.”

PEM: The Real Purpose

The PEM format exists for one simple reason: to make our lives easier.

Without PEM, sharing something like inter.key or web-server-der.crt in this blog would’ve been nearly impossible. That’s because DER is binary, and you can't just copy and paste binary content into a blog post. But PEM is Base64-encoded text — human-readable, portable, and perfect for pasting into emails, terminals, or blog posts like this one.

In fact, if you were too lazy to read my previous two blog posts or build your own CA setup (with intermediate and server certificates), PEM saves the day.

Just open a text editor and paste the following into a file named inter-pub.key:

Then, paste the following into a file named web-server-pem.crt:

Now convert this PEM certificate into DER format — just like the one I’ve used throughout this blog:

openssl x509 -in web-server-pem.crt -outform DER -out web-server-der.crt

These are the exact same key and certificate used in this blog. If you follow along, every single step — down to the signature bytes — will match. The only difference: you can skip Step 3 (extracting the public key), because you already have the public key as inter-pub.key.

That’s the beauty of structured cryptographic data and true reproducibility — same input, same result, every time.

Note: I only shared the public key of the Intermediate CA — the private key remains secure, as it always should be.

PKI With No Headache (Part 2): Asymmetric Keys, Digital Signing & X.509

Tarique Mehmood — Wed, 06 Aug 2025 10:51:16 +0000

Asymmetric Keys

The foundation of an X.509 certificate is its use of asymmetric keys, where a public key is mathematically derived from a private key. This relationship is intentionally one-way — it is computationally infeasible to reverse the process and retrieve the private key from the public key.

In practice, the private key is used to create digital signatures, while the public key is used to verify them. This asymmetry enables secure communication, authentication, and trust without the need to share secrets.

Digital Signing vs Encryption

At first glance, digital signing may seem similar to encryption, but it serves a completely different purpose. Encryption ensures confidentiality by hiding the contents of a message entirely. In contrast, digital signing focuses on authenticity and integrity — the message remains visible, but a separate piece of data, the signature, is attached.

To create this signature, a hash of the message is first computed (using algorithms like SHA or MD5), producing a unique fingerprint of the content. Then, only this hash is encrypted using the private key, resulting in the digital signature.

Signing Uses Encryption

You might say, “Wait — didn’t we encrypt something using the private key when creating the signature? Doesn’t that make it encryption?”

Well, yes — technically, something was encrypted. But here’s the key point: it wasn’t the message itself that was encrypted, but rather a hash — a compact fingerprint of the message.

This distinction is important. In signing, encryption is used as a tool to prove authenticity, not to hide content.

What a Signature Really Means

Digital signing is like saying to the other side:

"Here’s the data. You compute the hash yourself — I’ve already done the same and encrypted my result with my private key. Now compare your result with mine."

Since the signature was created using the private key, and only the corresponding public key can verify it, this proves that the signature came from the expected source and hasn’t been tampered with.

If the hashes match, the recipient can trust that the data is both authentic and intact.

Why Symmetric Keys Still Matter

Another question you might ask:

"Why not simply encrypt the entire message with the private key, so the recipient can skip hashing and just decrypt it using the public key?"

While that might sound reasonable, it doesn’t hold up in practice. Asymmetric encryption is far slower and less efficient than symmetric encryption — especially when handling large amounts of data.

That’s why symmetric encryption — where the same key is used for both encryption and decryption — remains the preferred method for securing actual message contents.

How HTTPS Applies Everything

It’s highly unlikely that someone saved this blog and emailed it to you — you’re probably reading it on a secure website, and the URL most likely starts with https. That means you're using TLS/SSL over HTTP. In this setup:

Asymmetric encryption is used first to securely exchange a symmetric key
Then, symmetric encryption takes over to efficiently handle the actual data transfer

Authenticity and integrity are ensured through digital certificates (X.509 v3) and asymmetric keys, while confidentiality is provided by the symmetric key.

Altogether, this means your connection is secure and trustworthy.

From Keys to Certificates

Suppose you need an X.509 v3 digital certificate to secure a web server. Naturally, the first step is to generate an asymmetric key pair. The next step is just as important: you’ll need to send your public key, along with some identifying details, to a Certificate Authority (CA).

But how? Email? Of course not — in the world of PKI, everything is governed by strict, standardized procedures.

This means you’ll need to follow a well-defined format and protocol to make that request. And that’s exactly where we’re headed next.

Certificate Signing Request (CSR)

A Certificate Signing Request (CSR) packages your public key along with your domain name, organization info, and other extensions into a formal, signed request.

Even in Part 1 of this series, the Intermediate CA had to create a CSR — which was then signed by the Root CA. The same rule applies to you.

Unless you're a Root CA, you can’t skip this step. Root CAs are the only entities that issue and sign their own certificates. That’s what makes a Root certificate truly self-signed.

Certificate Signing with Intermediate CA

In Part 1, we created an Intermediate CA — a subordinate certificate authority trusted by the Root CA. Now it’s time to put it to work.

But before signing anything, we need to generate a private key for the web server. This key will be used to create a CSR, which the Intermediate CA will eventually sign.

Step 1: Generate Private Key

openssl ecparam -name prime256v1 -genkey -noout -out web-server.key

This command generates an ECC private key using the NIST P-256 curve and saves it to web-server.key.

By default, OpenSSL generates RSA keys — but here, an ECC key is created intentionally for its compact size. This private key will later be used to generate a Certificate Signing Request (CSR).

Step 2: Create the CSR

openssl req -new -key web-server.key -out web-server.csr -subj "/CN=www.example.com"

This command creates a Certificate Signing Request (CSR). It bundles your public key and domain name (specified in the Common Name field) and signs it using your private key.

The resulting file, web-server.csr, is what you'll send to a Certificate Authority (CA) for signing.

Step 3: CA to Sign the CSR

openssl x509 -req -in web-server.csr \
  -CA inter.crt -CAkey inter.key -CAcreateserial \
  -outform DER -out web-server-der.crt -days 825 -sha256 \
  -extfile <(printf "keyUsage=digitalSignature,keyEncipherment\n\
extendedKeyUsage=serverAuth\n\
subjectAltName=DNS:www.example.com,DNS:example.com")

Command Breakdown

x509 — You're working with X.509 certificates
-req — Input is a CSR that needs to be signed
-in — The CSR file to be signed (web-server.csr)
-CA — The Intermediate CA’s certificate (inter.crt)
-CAkey — The Intermediate CA’s private key (inter.key)
-CAcreateserial — Auto-generates inter.srl to track serial numbers
-outform DER — Output format: binary DER, not PEM
-out — Output file for the signed certificate (web-server-der.crt)
-days 825 — Certificate validity: 825 days
-sha256 — Use SHA-256 for secure, modern signing
-extfile — Inject X.509 extensions from inline text

PEM vs DER

OpenSSL defaults to PEM format — it's Base64-encoded and human-readable in any text editor.

DER is the binary equivalent, typically used in web servers and systems that require compact, machine-friendly formats. Both encode the same certificate data — only the outer wrapping differs.

Extensions Added During Signing

These extensions are injected using -extfile and are critical for browser recognition and trust:

keyUsage = digitalSignature, keyEncipherment

Declares that the key is suitable for digital signing and key exchange.
extendedKeyUsage = serverAuth

Specifies that this certificate is valid for server authentication (HTTPS).
subjectAltName = DNS:www.example.com, DNS:example.com

Adds Subject Alternative Names (SAN) — required by all modern browsers.

Inspecting the Signed Certificate

Once the certificate is signed, you can inspect its contents using:

openssl x509 -in web-server-der.crt -inform DER -noout -text

This command decodes the DER-formatted certificate and displays its structure in a human-readable form:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            46:0d:9c:b0:fd:27:0f:6e:34:f2:b5:c3:60:c8:b0:6f:d4:77:23:b9
        # output truncated for brevity

Now you can verify everything — version, serial, issuer, subject, validity, extensions — all clearly laid out.

Wrapping Up

You’ve generated a private key, created a CSR, had it signed by a CA, and inspected the final certificate — all the core steps of issuing a web server certificate.

PKI doesn’t have to be a headache — and now you’ve seen why.

WireGuard Unlocked (Part 3): When and Why to Use NAT

Tarique Mehmood — Fri, 01 Aug 2025 21:25:02 +0000

I wasn’t planning to write a dedicated post about NAT — because in most situations, it’s simply not needed.

But when I was learning WireGuard myself, I ran into a flood of tutorials that used NAT without explaining why. Instead of helping, they often created confusion. After reviewing many of these setups, I realized NAT was being applied unnecessarily — sometimes even interfering with how WireGuard is supposed to work.

What’s Important?

The most critical concept to understand is AllowedIPs. This single setting controls both routing and access in WireGuard.

For outgoing traffic: the destination IP must match an entry in AllowedIPs.
For incoming traffic: the source IP must match an entry in AllowedIPs.

Because of this, AllowedIPs must be carefully mirrored on both peers. Whether you like this design or not, you cannot override or bypass it using traditional routing or NAT techniques.

So, Why NAT at All?

The most commonly used form of NAT is source NAT (SNAT) with port overloading — also known as masquerading. This is the default in most home routers, where private IPs (e.g., 192.168.1.x) are translated into a single public IP from the ISP.

If you have multiple peers using the same subnet, you can’t include them all in AllowedIPs — because their addresses will conflict. In such cases, NAT becomes useful. You can masquerade each peer’s LAN behind a unique WireGuard tunnel IP (like 10.x.x.x), allowing communication without exposing overlapping LANs.

Another practical case is when you want to send the LAN’s internet traffic through the WireGuard tunnel to the server — for example, to route internet access through a central location. In this setup, masquerading ensures that outbound packets are properly routed through the tunnel and back.

Also, just like traditional NAT, this breaks inbound connections. But in some cases, that’s a feature — a form of implicit security. If you don’t want to expose your LAN to the server side, masquerading is a valid solution.

NAT Implementation Example

Let’s reuse the topology from Part 1 or Part 2, where the server-side LAN is 172.19.2.0/24.

Now, say the client has a LAN subnet 192.168.8.0/24, but you don’t want to expose that network to the server — or you want to route LAN traffic to the internet via the server, or another peer already has the same subnet. Here’s what to do:

Do not include 192.168.8.0/24 in the server’s AllowedIPs.
On the client side, masquerade LAN traffic behind the WireGuard tunnel IP (e.g., 10.52.53.7) with this command:

iptables -t nat -A POSTROUTING -s 192.168.8.0/24 -o wg0 -j MASQUERADE

This ensures the server sees all packets as coming from 10.52.53.7, not from the internal LAN (192.168.8.x).

Verifying on the Client

To confirm the NAT rule is active, inspect the POSTROUTING chain:

root@vpn-client:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   20  1688 MASQUERADE  all  --  *      wg0     192.168.8.0/24       0.0.0.0/0

Final Thoughts

WireGuard is clean and predictable — but only if you understand AllowedIPs and don’t blindly apply NAT.

WireGuard Unlocked (Part 2): Deep Dive into AllowedIPs

Tarique Mehmood — Fri, 01 Aug 2025 21:23:00 +0000

WireGuard Unlocked (Part 2): Deep Dive into AllowedIPs

WireGuard doesn’t rely on routing daemons, ARP broadcasts, or complex protocol stacks. Instead, a single configuration setting — AllowedIPs — governs both the traffic that enters the tunnel and the traffic that’s accepted from a peer.

In this post, we’ll explore these behaviors through controlled experiments and packet captures.

Topology Overview

This is the same setup as in [Part 1], with one change:

We replaced the mobile client with two VMs.

Server-side VM: 192.168.8.2
Client-side VM: 172.19.2.2

This gives us a complete test path across the VPN tunnel, from one LAN to another.

VPN Server: `/etc/wireguard/wg0.conf`

[Interface]
PrivateKey = aEqKT6yuAYFrSuo7/gc2aVho6E63zURd7BSn7WtdCXQ=
Address = 10.52.53.1/24
MTU = 1420
ListenPort = 51820

[Peer]
PublicKey = 1eNRuE3LZekFTcXCCHoFyHxFUkmDRl+8XCLR6J1YV3s=
AllowedIPs = 10.52.53.7/32, 192.168.8.0/24

VPN Client: `/etc/wireguard/wg0.conf`

[Interface]
PrivateKey = 2Hif9GUJwZEWpH6eLTc0fchdAvqHF5/JaMvjxg/1rWM=
Address = 10.52.53.7/32
MTU = 1420

[Peer]
PublicKey = zaUBH5+F1DPx5Nn+DoEw6W+yqJLnhWYN7pElxzbi0Xc=
Endpoint = <server-ip>:51820
AllowedIPs = 10.52.53.1/32, 172.19.2.0/24
PersistentKeepalive = 25

AllowedIPs and the Routing Table

WireGuard uses the AllowedIPs list to populate the system routing table. Let’s confirm this on both ends.

On the Server

# WireGuard injects this route at startup:
systemctl status wg-quick@wg0 | grep 192.168.8.0/24
> ip -4 route add 192.168.8.0/24 dev wg0

# Confirm it:
ip route | grep 192.168.8.0/24
> 192.168.8.0/24 dev wg0 scope link

On the Client

systemctl status wg-quick@wg0 | grep 172.19.2.0/24
> ip -4 route add 172.19.2.0/24 dev wg0

ip route | grep 172.19.2.0/24
> 172.19.2.0/24 dev wg0 scope link

So far, AllowedIPs behaves like static routes injected at tunnel startup.

Testing the Behavior of AllowedIPs

We’ll examine two key behaviors:

To send: The destination IP must match a peer’s AllowedIPs.
To receive: The source IP must match the peer’s AllowedIPs.

Scenario: Remove Client LAN from Server’s AllowedIPs

On the server, comment out the client LAN:

[Peer]
PublicKey = 1eNRuE3LZekFTcXCCHoFyHxFUkmDRl+8XCLR6J1YV3s=
AllowedIPs = 10.52.53.7/32  # 192.168.8.0/24 is removed

Then add a manual route:

ip route add 192.168.8.0/24 dev wg0

Behavior 1: Client → Server Ping

Ping from 172.19.2.2 to 192.168.8.2 results in packets being rejected at the entry point.

WireGuard refuses to forward traffic to a destination not listed in the server’s AllowedIPs.

# On server:
tcpdump icmp -n
00:00:00 IP 172.19.2.2 > 192.168.8.2: ICMP echo request  
00:00:00 IP 172.19.2.1 > 172.19.2.2: ICMP host unreachable

Behavior 2: Server → Client Ping

Ping from 192.168.8.2 to 172.19.2.2 is unsuccessful.

Even though the route exists, WireGuard silently drops the packet because the source IP 192.168.8.2 is not listed in the server’s AllowedIPs.

# On client:
tcpdump icmp -n
00:00:00 IP 192.168.8.2 > 172.19.2.2: ICMP echo request  
00:00:00 IP 192.168.8.2 > 172.19.2.2: ICMP echo request  

# Server drops silently

Lessons Learned

AllowedIPs is directional.
Both peers must explicitly allow the traffic.
Static routes are ignored unless they match AllowedIPs.
WireGuard silently drops packets from unknown sources.
It behaves like a routing table and a firewall combined.
To enable full bi-directional communication, AllowedIPs must be mirrored on both peers.

AllowedIPs Restriction: One Network, One Peer

Problem Example

# Peer A
AllowedIPs = 192.168.100.0/24

# Peer B
AllowedIPs = 192.168.100.0/24  # Conflict!

You cannot have the same LAN behind multiple peers (without NAT or routing tricks).

WireGuard will pick one and ignore the rest.

Wrapping Up

WireGuard’s AllowedIPs is more than a route — it’s also an access control list.

To ensure reliable communication, both sides must explicitly agree on what’s allowed in and out.

In the next post, we’ll explore how NAT can help overcome its one-network-per-peer restriction.

WireGuard Unlocked (Part 1): Your LAN, Anywhere — The Easy Setup

Tarique Mehmood — Fri, 01 Aug 2025 21:19:30 +0000

WireGuard really surprised me. It seemed like just another VPN at first, but under the hood, it follows a minimal and highly efficient design. By doing less, it achieves more speed, security, and reliability without the usual VPN complexity.

Still, many people struggle with things like peer setup, AllowedIPs, NAT or routing logic. So I’m starting this series with the most common use case: securely accessing your home or office LAN from a mobile phone or laptop.

Topology Overview

We have three devices in this setup:

VPN Server — Acts as the central relay with a public IP. It listens for incoming WireGuard connections from clients.
VPN Client (Ubuntu) — Connects to the server to access the server-side LAN. It also exposes its own LAN to the server and other peers.
VPN Client (Android) — Runs the official WireGuard app. It connects to the server and can access both the client’s and server’s LANs.

All devices share the same WireGuard subnet: 10.52.53.0/24.

The server uses a /24 mask because it communicates with multiple clients.
Clients use /32 masks since they only need to route their own traffic through the tunnel.

Installing WireGuard

Before we configure anything, let’s install WireGuard on both the Ubuntu server and Ubuntu client:

sudo apt install wireguard

Generating Keys

WireGuard is based on public-key cryptography. Each device must have its own key pair — one private key (kept secret) and one public key (shared with peers).

To generate a key pair:

wg genkey | tee privatekey | wg pubkey > publickey

Or use these quick one-liners for each device:

PRIV=$(wg genkey); PUB=$(echo "$PRIV" | wg pubkey); echo "Server PrivateKey: $PRIV"; echo "Server PublicKey: $PUB"
PRIV=$(wg genkey); PUB=$(echo "$PRIV" | wg pubkey); echo "Client PrivateKey: $PRIV"; echo "Client PublicKey: $PUB"
PRIV=$(wg genkey); PUB=$(echo "$PRIV" | wg pubkey); echo "Mobile PrivateKey: $PRIV"; echo "Mobile PublicKey: $PUB"

WireGuard Config File (`/etc/wireguard/wg0.conf`)

The WireGuard configuration file is divided into two main parts:

Interface Section

Defines local settings for the wg0 interface. At minimum, specify:

PrivateKey — your device’s private key
Address — the IP address for the WireGuard interface
MTU — optional but recommended to prevent fragmentation (e.g., 1420)
ListenPort — required for servers (e.g., 51820)

Peer Section

Defines each remote peer and how to reach them. For each peer, specify:

PublicKey — the peer’s public key
Endpoint — the public IP and port of the peer (required on clients)
AllowedIPs — IP ranges routed via the peer
PersistentKeepalive — optional but recommended on clients behind NAT

Server Configuration

Edit the file /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = aEqKT6yuAYFrSuo7/gc2aVho6E63zURd7BSn7WtdCXQ=
Address = 10.52.53.1/24
MTU = 1420
ListenPort = 51820

# Ubuntu Client
[Peer]
PublicKey = 1eNRuE3LZekFTcXCCHoFyHxFUkmDRl+8XCLR6J1YV3s=
AllowedIPs = 10.52.53.7/32, 192.168.8.0/24

# Android Client
[Peer]
PublicKey = T2zmNnnRoBJDp+UCSl0VrSndEllyHbDsJNIXFuFJgQU=
AllowedIPs = 10.52.53.14/32

Enable IP forwarding:

sudo sysctl -w net.ipv4.ip_forward=1

Then enable and start WireGuard:

sudo systemctl enable wg-quick@wg0 --now

Client Configuration

Edit /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = 2Hif9GUJwZEWpH6eLTc0fchdAvqHF5/JaMvjxg/1rWM=
Address = 10.52.53.7/32
MTU = 1420

[Peer]
PublicKey = zaUBH5+F1DPx5Nn+DoEw6W+yqJLnhWYN7pElxzbi0Xc=
Endpoint = <server-ip>:51820
AllowedIPs = 10.52.53.1/32, 10.52.53.14/32, 172.19.2.0/24
PersistentKeepalive = 25

Then enable and start WireGuard:

sudo systemctl enable wg-quick@wg0 --now

Mobile Configuration

Install the official WireGuard app from the Play Store.

Tap the ➕ button to add a new tunnel manually:

[Interface]
PrivateKey = 0N65LkXXXfmyceCqzP7X/0Yy2tldBywaDdU6ox2BFVM=
Address = 10.52.53.14/32
MTU = 1420

[Peer]
PublicKey = zaUBH5+F1DPx5Nn+DoEw6W+yqJLnhWYN7pElxzbi0Xc=
Endpoint = <server-ip>:51820
AllowedIPs = 10.52.53.1/32, 10.52.53.7/32, 172.19.2.0/24, 192.168.8.0/24
PersistentKeepalive = 25

This is how the VPN looks in the mobile app:

Verification & Testing

Once all devices are configured and connected:

From the Server:

ping 10.52.53.7
ping 10.52.53.14
ping 192.168.8.1

From the Client:

ping 172.19.2.1 
ping 10.52.53.14

Wrapping Up

This guide walked you through a step-by-step setup of WireGuard — from generating keys to full configuration across a server, client, and mobile device. In the next post, I’ll dive deeper into how WireGuard handles routing, peer discovery, and the magic behind AllowedIPs.

For now, just follow the instructions as shown — and keep in mind, you don’t need a cloud VPS to try this. All three devices can be on the same network, like your home LAN. It’s a great way to get comfortable with the setup before going remote.

PKI With No Headache (Part 1): A Real World Example

Tarique Mehmood — Fri, 01 Aug 2025 21:00:05 +0000

Every time you visit a secure website — like https://google.com — your browser quietly checks whether the site’s certificate was issued by a trusted Certificate Authority (CA). One of the most widely used CA systems in the world is Let’s Encrypt, which has issued over 3 billion certificates and powers a massive portion of the internet.

Let’s Encrypt and other industry leaders like DigiCert and GlobalSign use a two-tier certificate hierarchy — a Root CA and one or more Intermediate CAs.

In this post, we’re going to build that exact system — a minimal, fully working CA setup with the same two-tier hierarchy:

A Root CA (self-signed)
An Intermediate CA (signed by the root)

It’s a real, functional CA you can use to issue certificates — just like the big players do.

We’ll use OpenSSL and basic Linux commands throughout this series.

Step 1: Generate CA Private Key

Let’s begin by creating the private key for our Root CA:

openssl genrsa -out ca.key 2048

This generates ca.key — a PEM-formatted private key using the PKCS#1 standard. It’s only about 1 KB in size, but it holds absolute power.

If the private key of a real Root CA like Let’s Encrypt were ever leaked, over 3 billion certificates would become instantly untrusted — triggering a digital earthquake across the internet.

To prevent that kind of disaster, the Root CA is kept offline and used only to sign Intermediate CA certificates. These intermediates handle day-to-day operations and remain online — keeping the root key locked away and safe.

Step 2: Create the Root Certificate (X.509v3)

In the world of PKI, different entities use different types of certificates:

Root CA — self-signed certificate that anchors trust
Intermediate CA — signed by Root CA, used to issue certificates
Leaf Node (e.g., web server) — signed by Intermediate, used by clients like browsers

What’s in an X.509v3 certificate?

Version (v3)
Serial number
Signature algorithm
Issuer (who signed it)
Validity (start and end dates)
Subject (identity being certified)
Public Key Info
Extensions (KeyUsage, BasicConstraints, etc.)
Signature (created using issuer’s private key)

Since this is a Root CA certificate, it will be self-signed — the issuer and subject are the same.

Generate the Root Certificate

openssl req -x509 -new -key ca.key -out ca.crt -days 3650 -subj "/CN=PKIWNH Root CA"

Breakdown:

-x509 — generate a certificate instead of a CSR
-new — create a new cert
-key ca.key — use the root private key
-out ca.crt — write to this file
-days 3650 — valid for 10 years
-subj — subject name (CN only here)

Step 3: Create the Intermediate CA

Now that we have our Root CA (ca.key + ca.crt), it’s time to create the Intermediate CA — the one that actually issues certificates.

This is how it works in real-world CA systems like Let’s Encrypt and DigiCert.

The Root stays offline, and the Intermediate does all the signing. We’ll follow these steps:

Generate a private key
Create a Certificate Signing Request (CSR)
Sign the CSR with the Root CA

Step 3.1: Generate Intermediate Private Key

openssl genrsa -out inter.key 2048

This key will be used to sign leaf certificates (like web servers).

Step 3.2: Create CSR (Certificate Signing Request)

openssl req -new -key inter.key -out inter.csr -subj "/CN=PKIWNH Intermediate CA"

The CSR includes the subject and public key. It will be signed by the Root CA to become a valid certificate.

Step 3.3: Sign the CSR with Root CA

openssl x509 -req -in inter.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out inter.crt -days 1825

This command creates inter.crt — a real Intermediate CA certificate valid for 5 years, signed by your Root CA.

Explanation:

-CAcreateserial — creates a ca.srl file for serial tracking
-CA and -CAkey — specify the Root CA used to sign
-in and -out — input CSR and output certificate

At this point, you have a working two-tier CA system:

ca.crt (Root CA) — used only to sign Intermediate certificates
ca.key — must be kept offline and secure
inter.crt + inter.key — used to sign leaf certificates

Just like Let’s Encrypt or DigiCert, your Root CA stays offline while your Intermediate CA goes live.

Wrap Up

The only difference between your CA and a commercial one?

Their Root CAs are pre-installed in billions of devices (browsers, OS, phones).

Yours is not trusted yet.

To use your CA in the real world, you’ll need to manually install your Root CA certificate on every system that needs to trust it — Windows, Android, Linux, or even just your browser.

Next Up (Part 2): We’ll dive into X.509 — its format (PEM/DER), verification process, and key extensions like Key Usage and SAN.

DEV Community: Tarique Mehmood

PKI With No Headache (Part 3): Bits, Bytes, and Trust

When PKI Becomes a Black Box

Who Cares About ASN.1 and DER?

RFC 5280 Section 4.1

Briefly, What is DER?

Back to the ASN.1

Manually Verifying a Certificate Signature

Step 1: Extract tbsCertificate

Step 2: Extract signatureValue

Step 3: Decrypt the CA’s Signature

Step 4: Calculate the Hash of the TBS Part

PEM: The Real Purpose

PKI With No Headache (Part 2): Asymmetric Keys, Digital Signing & X.509

Asymmetric Keys

Digital Signing vs Encryption

Signing Uses Encryption

What a Signature Really Means

Why Symmetric Keys Still Matter

How HTTPS Applies Everything

From Keys to Certificates

Certificate Signing Request (CSR)

Certificate Signing with Intermediate CA

Step 1: Generate Private Key

Step 2: Create the CSR

Step 3: CA to Sign the CSR

Command Breakdown

PEM vs DER

Extensions Added During Signing

Inspecting the Signed Certificate

Wrapping Up

WireGuard Unlocked (Part 3): When and Why to Use NAT

What’s Important?

So, Why NAT at All?

NAT Implementation Example

Verifying on the Client

Final Thoughts

WireGuard Unlocked (Part 2): Deep Dive into AllowedIPs

WireGuard Unlocked (Part 2): Deep Dive into AllowedIPs

Topology Overview

VPN Server: /etc/wireguard/wg0.conf

VPN Client: /etc/wireguard/wg0.conf

AllowedIPs and the Routing Table

On the Server

On the Client

Testing the Behavior of AllowedIPs

Scenario: Remove Client LAN from Server’s AllowedIPs

Behavior 1: Client → Server Ping

Behavior 2: Server → Client Ping

Lessons Learned

AllowedIPs Restriction: One Network, One Peer

Problem Example

Wrapping Up

WireGuard Unlocked (Part 1): Your LAN, Anywhere — The Easy Setup

Topology Overview

Installing WireGuard

Generating Keys

WireGuard Config File (/etc/wireguard/wg0.conf)

Interface Section

Peer Section

Server Configuration

Client Configuration

Mobile Configuration

Verification & Testing

Wrapping Up

PKI With No Headache (Part 1): A Real World Example

Step 1: Generate CA Private Key

Step 2: Create the Root Certificate (X.509v3)

What’s in an X.509v3 certificate?

Generate the Root Certificate

Step 3: Create the Intermediate CA

Step 3.1: Generate Intermediate Private Key

Step 3.2: Create CSR (Certificate Signing Request)

Step 3.3: Sign the CSR with Root CA

Wrap Up

Step 1: Extract `tbsCertificate`

Step 2: Extract `signatureValue`

VPN Server: `/etc/wireguard/wg0.conf`

VPN Client: `/etc/wireguard/wg0.conf`

WireGuard Config File (`/etc/wireguard/wg0.conf`)