Posts

Creating a private Root CA and signing a server certificate (with SAN)

  Notes for the reader Run all commands from a single working folder. Protect rootCA.key (this is the CA signing key). Do not share it. Clients must trust the Root CA certificate ( rootCA.pem ) or they will still see certificate warnings. Creating Root CA key and certificate 1. Create your own Root CA private key (rootCA.key) Recommended: encrypt the Root CA key with a passphrase. openssl genrsa -aes256 -out rootCA.key 4096 If you do not want a passphrase (not recommended), use: openssl genrsa -out rootCA.key 4096 2. Create openssl.cfg (Root CA certificate config) Create a file called openssl.cfg using Notepad and paste the following. Update C, ST, L, O, OU, CN as needed. Important: The Root CA CN should be a CA name (example: “Company Root CA”), not a device hostname. [req] distinguished_name = req_distinguished_name x509_extensions = v3_ca prompt = no default_md = sha256 [req_distinguished_name] C = CA ST = ON L = Toronto O = Company OU = IT CN = Company Root CA [v3_ca] #...

Manually Self-Signing a Kernel Module on RHEL with Secure Boot Enabled

This document describes how to self-sign a third-party kernel module on RHEL 9 so it can be loaded when Secure Boot is enabled. Scope: Applies to any out-of-tree / third-party kernel module ( .ko ). Does not cover how to build or install the module itself — only how to sign and load it with Secure Boot enabled. 0. Preconditions RHEL 9.x with Secure Boot enabled The kernel module is already built for the running kernel and installed somewhere under: /lib/modules/$(uname -r)/... or you know the full path to the .ko file. Root access and ability to: Reboot the system Interact with the MOK Manager screen at boot Install required packages: sudo dnf install -y \ mokutil \ openssl \ "kernel-devel-$(uname -r)" \ "kernel-headers-$(uname -r)" 1. Confirm the kernel module exists Replace <module_name> with the module you want to sign (for example, mydriver ): sudo -i modinfo <module_name> || echo "module not found" If modinfo prints metadata,...

Run Cisco CML 2.9.x on KVM (virt-manager)

Cisco Modeling Labs (CML) is an awesome way to practice routing/switching labs without owning physical gear. The catch: Cisco primarily distributes CML as an OVA (Open Virtual Appliance), which is most commonly used with VMware products. If you’re on Linux and prefer KVM/libvirt (or you just don’t want to use VMware), you’re not stuck. This guide walks through the full process of running Cisco CML 2.9.x on KVM using virt-manager, including importing the refplat image bundle so you can actually add routers and switches in your labs. What you’ll achieve By the end, you’ll have: A working CML controller VM running on KVM Access to: CML Web UI (where you build labs) Cockpit (system admin/maintenance) refplat imported, so you can add router/switch nodes like IOSv and IOSvL2 About the CML Free Version (the one I’m using) For this setup I’m using the CML free/personal release. It’s perfect for learning and building small labs, but it has limits compared to a paid licens...

DTP and VTP

DTP explained here: DTP, stands for Dynamic Trunking Protocol, is a cisco proprietary protocol. DTP allows ports to be configured for operating trunk mode automatically based on which administrative mode the switchport is on and which administrative or manual mode the switchport that is connected to it is on. Interfaces on old switches, switchport mode is dynamic desirable but interfaces on new cisco switches, switch mode is dynamic auto. Trunk mode do not do DTP negotiation. Dynamic Desirable can form trunk, also actively want to form trunk. Dynamic Auto can form trunk but do not actively want to form trunk. Access port do not do DTP negotiation. DTP Administrative Mode Outcomes If a port is set to Trunk : With Trunk → Trunk With Dynamic Desirable → Trunk With Access → No trunk (X) With Dynamic Auto → Trunk If a port is set to Dynamic Desirable : With Trunk → Trunk With Dynamic Desirable → Trunk With Access → Access With ...

About RSTP (Rapid Spanning Tree Protocol)

Rapid Spanning Tree Protocol starts here. This is how it works: Blocks ports to prevent loops. Same rules for root bridge selection as STP Same rules for root port selection as STP Same rules for designated port selection as STP Takes less than 30 seconds to move a port from blocking to forwarding state; thus, the name “Rapid”. 1st difference of RSTP from STP is RSTP root cost: STP vs RSTP Path Cost by Link Speed 10 Mbps STP cost: 100 RSTP cost: 2,000,000 100 Mbps STP cost: 19 RSTP cost: 200,000 1 Gbps STP cost: 4 RSTP cost: 20,000 10 Gbps STP cost: 2 RSTP cost: 2,000 100 Gbps STP cost: Not defined RSTP cost: 200 1 Tbps STP cost: Not defined RSTP cost: 20 2nd difference will be in port states: STP Port States (Discarding / Learning / Forwarding) Discarding (Stable) BPDUs: Send No / Receive Yes MAC learning: No Forward traffic: No Learning (Transitional) BPDUs: Send Yes / Receive Yes MAC learning: Yes Forward traffic: No Forwarding (Stable) BPDUs: S...

About STP (Spanning Tree Protocol) | Part 2

Image
Continuing after Part 1 :   Blocking and Forwarding states are stable states. There are two other states: Listening & Learning. These are transitional state. I have tried to learn the different states in STP by differentiating them by a few things that they do or do not. These things are: 1. Do they send or receive STP BPDUs? 2. Do they learn mac addresses? 3. Do they receive and forward regular traffic? STP Port States (Summary) Blocking (Stable) BPDU: Send No / Receive Yes MAC learning: No Forward traffic: No Listening (Transitional) BPDU: Send Yes / Receive Yes MAC learning: No Forward traffic: No Learning (Transitional) BPDU: Send Yes / Receive Yes MAC learning: Yes Forward traffic: No Forwarding (Stable) BPDU: Send Yes / Receive Yes MAC learning: Yes Forward traffic: Yes  Wireshark STP packet capture:   Portfast : Portfast is called a toolkit (optional feature) of STP that solves one problem of STP. As soon as a s...

About STP (Spanning Tree Protocol) | Part 1

Image
Spanning Tree Protocol (STP) is a Layer 2 protocol that prevents switching loops and broadcast storms by placing redundant links into a blocking state when necessary. Here what the protocol STP is and can do and is used for: STP is a layer 2 protocol. Stops layer 2 loops/broadcast storms. Used for redundancy. With STP it is possible to implement multiple paths to a destination. Done by changing the state of a redundant port to blocking state. Blocking state ports can change to forwarding state if any forwarding port fails. By putting some ports in forwarding and some ports in blocking, there is always a single path between two points in a network. How it works: Ports that have STP enabled sends and receives “Hello BPDU” messages. Hello BPDU messages are send out of STP enabled ports every 2 seconds. BPDU stands for Bridged Protocol Data Unit. If Hello BPDU message is received on any STP enabled port, the switch that receives it understands that the interface that the STP enabled port ...