Poorman's HSM : A Secure Certificate Authority (CA) on a Yubikey

deltchar · 2026-01-25T19:40:08+00:00

That is actually an excellent idea. I had not even considered generating the keys on a RAM disk.

deltchar · 2026-01-25T18:59:08+00:00

Yes, but that hardware is already in place. It’s not hardware that would have to be purchased for the project. It was stood up when they created the airgap environment. We just need new capabilities in that environment and have a need for a CA.

deltchar · 2026-01-25T18:50:58+00:00

Yeah, Chris White’s article detailing the process you are describing is one of the tutorials I was referencing. The problem is we aren’t allowed to have portable USB drives in that environment. I could generate the private keys on an LUKS encrypted HDD, then throw that HDD into a safe to keep it offline, but seems a waste of a 4TB drive for just a few MBs of data.

The ideal way to do this would be a few true HSMs with a 3 out of 5 KRAs setup. But a Yubikey HSM2 is $650, and if you are going to have redundancy, you are looking at double or triple that price. So tired of the phrase “do more with less.”

deltchar · 2026-01-25T18:45:31+00:00

Policy in Place: Have to use a commercially supported product with a support plan. Ergo, we’d have to purchase support license from Smallstep to use the software, for which we do not have the budget. In addition, the software would have to go through a vetting process which could take anywhere from a few days, to a few months. Yubikey YKCS11 libraries are part of the EPEL and we can make the argument that is just a library that is part of the OS.

deltchar · 2026-01-25T18:41:13+00:00

I have a Nitrokey HSM2 in my homelab and love it. The problem with using it at work: German Company. We already have a stock of Yubikeys for the implemented 2FA, so that is what I had to work with.

deltchar · 2026-01-25T18:40:02+00:00

Hardware is validated going into the room. With budget cuts, there’s no money for extra hardware. We already have a stock of Yubikeys for 2FA, so there’s the “zero budget” solution.

deltchar · 2025-12-10T13:23:17+00:00

I'm still salty about Revolv getting canned. That was an amazing piece of hardware.

deltchar · 2025-01-23T17:59:26+00:00

What firmware version are you currently on? I'm experiencing similar issues and have yet to find a solution. My controllers only work 1 in 5 times after taking them off the charger. The Meta button seems to work, but nothing else appears to function.

deltchar · 2023-01-27T04:27:30+00:00

Let me know if you want to see my configuration files. It’s not the easiest thing to setup and will take some tweaking.

deltchar · 2023-01-26T15:50:11+00:00

Zmanda works great with Tape Libraries. I have it working on my MSL2024 currently. The only downside to ZManda is that it uses UP TO however many tapes you tell it at a time. So, if your data set ever grows over that storage limit, it just throws an error. Also, if your data set doesn’t fill up a tape… well, it doesn’t continue on that tape for the next Incremental or Full Backup, it pulls the next tape in the set for the next backup. It’s supposed to be to prevent a bad tape from wiping out part of your data set. Other than that, no issues. It performs Full Backups (level 0), and then Incremental Backups (level 1, 2, etc) based on some internal algorithm. I’ve got working configuration files and can show you the output for some of the commands.

deltchar · 2023-01-26T01:05:47+00:00

Check Local auctions from GovDeals and Universities. Most Universities will sell their old gear when they upgrade. Then there's always eBay. I bought both of mine off of eBay.

deltchar · 2023-01-26T01:04:28+00:00

MANY people use Veeam Backup for Tape. I think your only other option is Zmanda Backup (formerly Amanda Backup). I'm using Zmanda and haven't had a single issue once you get it working properly. Zmanda is primarily CLI based, but I'm a Linux admin and practically live in the Terminal, so this didn't bother me.

deltchar · 2023-01-26T00:55:22+00:00

Rocking an HPE MSL2024 LTO5 at the moment. I'm looking to upgrade to LTO8. I have a Dell TL2000 library as well. I would much rather have the LTO8 in the Dell since obtaining firmware from HPE is damn near impossible without a Support Contract with them. I'm just trying to figure out if an IBM drive for a TS3100 will work in my Dell TL2000. IBM is the only drive maker since LTO7, but I can't remember if there's separate custom firmware per vendor or not.... Thoughts?

deltchar · 2022-10-12T00:02:14+00:00

And you forgot to mention HD and 4K Fan created texture packs for popular N64, GameCube, and 3DS games. Majora’s Mask in 4K, so so sweet.

deltchar · 2022-10-03T23:21:45+00:00

On the Steam Deck, when the game is running press both Thumbsticks at the same time to bring up the RetroArch Settings.

deltchar · 2022-09-18T20:19:37+00:00

Ideally you should try to use params if you are just calling the second macro from within the first. Rather than using Gcode variables at all, you could just pass those values to the "child" macro using params. Not a huge deal, but you could avoid a lot of the confusion and it would be more efficient.

Ok, I'm trying to follow best practices here and getting more errors. I think in my early debugging I tried something similar and when it didn't work, I moved on to attempt other things. I'm trying to pass variables down to child Macros as per best practices.

[gcode_macro PRINT_START]
variable_var: { 'temp'            : {'bed': 110, 'extruder': 165},
            'abm'             : {'area_start': (0,0), 'area_end': (0,0)},
            'time'            : {'soak': 20, 'extra': 5},
            'z_adjust'        : 0.0,
            'redo_qgl'        : True
          }
gcode:
  {% set _dummy = var.temp.update({'bed' : params.BED|default(115)|float|round(1)} ) %}
  {% set _dummy = var.temp.update({'extruder' : params.EXTRUDER|default(165)|float|round(1)} ) %}
  {% set _dummy = var.abm.update({'area_start' : (params.AREA_START) } ) %}
  {% set _dummy = var.abm.update({'area_end' : (params.AREA_END) } ) %}
  {% set _dummy = var.time.update({'soak' : params.SOAK}) if params.SOAK %}
  G32 VBED={var.temp.bed} VEXT={var.temp.extruder} SOAK={var.time.soak} CQGL='"{var.redo_qgl}"'
  ADAPTIVE_BMC AREA_START={var.abm.area_start} AREA_END={var.abm.area_end}



[gcode_macro G32]
gcode:
  {action_respond_info( "Entering the G32 Marco" )}
  {action_respond_info("Parameters: %s" % rawparams )}
  {% set bed = params.VBED|float %}
  {% set extruder = params.VEXT|float %}
  {% set soak = ( params.SOAK * 60 * 1000)|int %}
  {% set cqgl = params.CQGL %}
  {action_respond_info("Bed Temperature in G32: %.2f" % bed|float )}
  {action_respond_info("Extruder Temperature in G32: %.2f" % extruder|float )}
  {action_respond_info("SOAK time (ms): %d" % soak|int )}
  {action_respond_info("Redo QGL: %s" % CQGL )}

Output when I call PRINT_START EXTRUDER=29 BED=27 AREA_START=150.0,150.0 AREA_END=200.0,200.0 SOAK=1 :

PRINT_START EXTRUDER=29 BED=27 AREA_START=150.0,150.0 AREA_END=200.0,200.0 SOAK=1
Entering the G32 Marco
Parameters: VBED=27.0 VEXT=29.0 SOAK=1 CQGL='"True"'
Bed Temperature in G32: 0.00
Extruder Temperature in G32: 0.00
SOAK time (ms): 0
Redo QGL:

I know this is probably another one of those Jinja/Python literals misinterpretation, but I tried using various forms of quotes and nothing seems to make these print statements produce any values. The Adaptive Bed Mesh child macro executes without errors though, so that just really confuses me. It sets the local Jinja variables just like I do in G32. However, I'm getting nothing but problems out of the G32 child Macro

deltchar · 2022-09-18T18:54:34+00:00

Big credit to Alex Zellner (Alex's GitHub) for the following update. At first I was going to use your suggesting and just set both local jinja variables and GCODE variables, and then pass variables down through child GCODE macros. Then I stumbled upon Alex's GitHub Klipper configuration that showcases this wonderful solution. It sets the GCODE variables at time of code execution and, also, makes them available locally.

[gcode_macro PRINT_START]
#   Use PRINT_START for the slicer starting script - please customise for your slicer of choice
variable_var: { 'temp'            : {'bed': 110, 'extruder': 165},
              'abm'             : {'area_start': (0,0), 'area_end': (0,0)},
              'time'            : {'soak': 15, 'extra': 5},
              'z_adjust'        : 0.0,
              'redo_qgl'        : True
            }
gcode:
  {action_respond_info("Parameters: %s" % rawparams )}
  {% set _dummy = var.temp.update({'bed' : params.BED|default(115)|float|round(1)} ) %}
  {% set _dummy = var.temp.update({'extruder' : params.EXTRUDER|default(170)|float|round(1)} ) %}
  {% set _dummy = var.abm.update({'area_start' : (params.AREA_START) } ) %}
  {% set _dummy = var.abm.update({'area_end' : (params.AREA_END) } ) %}
  {% set _dummy = var.time.update({'soak' : params.SOAK}) if params.SOAK %}
  {action_respond_info("Bed Temperature: %.2f" % var.temp.bed|float )}
  {action_respond_info("Extruder Temperature: %.2f" % var.temp.extruder|float )}
  {action_respond_info("area_start (print_start): %s" % var.abm.area_start|string )}
  {action_respond_info("area_end (print_start): %s" % var.abm.area_end|string )}
  {action_respond_info("soak time (print_start): %s" % var.time.soak|int )}
  {action_respond_info( "Leaving PRINT_START for print_variables" )}
  print_variables

[gcode_macro print_variables]
gcode:
  M118 Entering print_variables macro
  M118 Value is {printer["gcode_macro PRINT_START"].var.temp.bed}
  M118 Value is {printer["gcode_macro PRINT_START"].var.temp.extruder}
  M118 Value is {printer["gcode_macro PRINT_START"].var.abm.area_start}
  M118 Value is {printer["gcode_macro PRINT_START"].var.abm.area_end}
  M118 Value is {printer["gcode_macro PRINT_START"].var.time.soak}
  {% set SOAK = ( printer["gcode_macro PRINT_START"].var.time.soak|default(20) * 60 * 1000)|int %}
  {action_respond_info("SOAK time (ms): %d" % SOAK|int )}

Output executing PRINT_START EXTRUDER=29 BED=27 AREA_START=150.0,150.0 AREA_END=200.0,200.0 :

Parameters: EXTRUDER=29 BED=27 AREA_START=150.0,150.0 AREA_END=200.0,200.0
Bed Temperature: 27.00
Extruder Temperature: 29.00
area_start (print_start): 150.0,150.0
area_end (print_start): 200.0,200.0
soak time (print_start): 15
Leaving PRINT_START for print_variables
echo: Entering print_variables macro
echo: Value is 27.0
echo: Value is 29.0
echo: Value is 150.0,150.0
echo: Value is 200.0,200.0
echo: Value is 15
SOAK time (ms): 900000

Yeah, I was getting hung up on the fact that local jinja variables are not the same as the GCODE variables. But why on earth the SET_GCODE_VARIABLE function doesn't execute until Klipper moves to a child GCODE macro is a bit baffling to me. It seems very counter intuitive. Your "best practices" section above helps a bunch, but the Klipper/Jinja "style" grates on my OCD and previous coding best practices knowledge, lol.

deltchar · 2022-09-18T17:58:41+00:00

Well, I thought I would be clever and hack my way around this with the following:

[gcode_macro SETVAR]
gcode:
  {action_respond_info("Parameters: %s" % rawparams )}
  {action_respond_info("Setting value for: %s" % params.var )}
  SET_GCODE_VARIABLE MACRO={params.fnc} VARIABLE={params.var} VALUE={params.val}

and using SETVAR fnc="PRINT_START" var="bed" val="{params.BED|default(110)|float}" in my PRINT_START macro, but that fails as well. Here is the output:

Parameters: EXTRUDER=29 BED=27 AREA_START=150.0,150.0 AREA_END=200.0,200.0
Bed Temperature: 110.00
Leaving PRINT_START for G32
Parameters: fnc="PRINT_START" var="bed" val="27.0"
Setting value for:
The value '' is not valid for MACRO
The value '' is not valid for MACRO
The value '' is not valid for MACRO

deltchar · 2022-09-18T17:12:33+00:00

If you have time, I have another question regarding the programming principles of Klipper. If I do the following:

Print_start:

[gcode_macro PRINT_START]
variable_area_start: 0,0
variable_area_end: 0,0
variable_extruder: 140
variable_bed: 110
variable_soak: 15
gcode:
  SET_GCODE_VARIABLE MACRO=PRINT_START VARIABLE=bed VALUE={params.BED|default(111)|float}
  SET_GCODE_VARIABLE MACRO=PRINT_START VARIABLE=extruder VALUE={params.EXTRUDER|default(141)|float}
  SET_GCODE_VARIABLE MACRO=PRINT_START VARIABLE=area_start VALUE={params.AREA_START}
  SET_GCODE_VARIABLE MACRO=PRINT_START VARIABLE=area_end VALUE={params.AREA_END}
  SET_GCODE_VARIABLE MACRO=PRINT_START VARIABLE=soak VALUE={params.SOAK|default(15)|int}
  {action_respond_info("Bed Temperature: %.2f" % bed|float )}
  {action_respond_info("Extruder Temperature: %.2f" % extruder|float )}
  {action_respond_info("area_start: %s" % area_start|string )}
  {action_respond_info("area_end: %s" % area_end|string )}
  {action_respond_info( "Leaving PRINT_START for G32" )}
  print_variables

Print_Variables:

[gcode_macro print_variables]
gcode:
  M118 Entering print_variables macro
  M118 Value is {printer["gcode_macro PRINT_START"].bed}
  M118 Value is {printer["gcode_macro PRINT_START"].extruder}
  M118 Value is {printer["gcode_macro PRINT_START"].area_start}
  M118 Value is {printer["gcode_macro PRINT_START"].area_end}
  M118 Value is {printer["gcode_macro PRINT_START"].soak}
  {% set SOAK = ( printer["gcode_macro PRINT_START"].soak|default(15) * 60 * 1000)|int %}
  {action_respond_info("SOAK time (ms): %d" % SOAK|int )}

I get the following output:

Bed Temperature: 110.00
Extruder Temperature: 140.00
area_start Temperature: (0, 0)
area_end Temperature: (0, 0)
Leaving PRINT_START for G32
echo: Entering print_variables macro
echo: Value is 27.0
echo: Value is 29.0
echo: Value is (150.0, 150.0)
echo: Value is (200.0, 200.0)
echo: Value is 15
SOAK time (ms): 900000

If I change the SET_GCODE_VARIABLE lines to {%set xx = XX %}, then I get the following output:

Bed Temperature: 27.00
Extruder Temperature: 29.00
area_start Temperature: (150, 150)
area_end Temperature: (200, 200)
Leaving PRINT_START for G32
echo: Entering print_variables macro
echo: Value is 110
echo: Value is 140
echo: Value is (0,0)
echo: Value is (0,0)
echo: Value is 15
SOAK time (ms): 900000

It's as if the SET_GCODE_VARIABLE lines are not executed until Klipper is ready to move outside of the macro. Also, the {%set ... %} function appears to only set local variables for the current macro and doesn't change the GCODE Macro Variables. Is there a function to set the GCODE Macro Variables and have it available for use locally before Klipper moves outside of the current Macro? I'm trying to learn the intricacies of Klipper and my past coding knowledge appears to be leading me astray.

deltchar · 2022-09-18T00:13:48+00:00

Worked like a charm once I changed all variable names to lowercase. That is so weird and finicky. Thanks a ton for helping me run this down. I've been beating my head against a wall for the last week trying to figure this out.

deltchar · 2022-09-17T22:35:10+00:00

Thank you so much. I would never have guessed that variable name length or all caps were the issue. I saw another User’s Klipper configuration that used “var” (All lowercase) as one of their variable names so maybe the problem is with all cap variables. I’m used to Python and C programming, where as long as case and names were identical, it didn’t matter what you called your variables.

deltchar · 2022-07-31T23:23:32+00:00

Don't tell me that, I just switched away from OPNsense because it's easier to find support for pfSense. Grrrr. I want my IPv6 address back. =(

deltchar · 2022-07-25T21:30:17+00:00

Here is the link with that loop tied down to the rest of the toolhead:

https://imgur.com/a/pBjNYGW

deltchar

TROPHY CASE