Environment:
I have a server with services I'd like to expose using a public facing domain (FQDN) with several layers of authentication to protect the sites from outside eyes and potentially creating an attack surface.

My home lab and network setup:

1. 1GB fiber to the house with single external IP address
2. Edge Reverse Proxy - configured to ingest external requests and pass them along to internal servers. I terminate :80 at this server and return a 301 to force any :80 requests up to :443 -> which then sends the traffic as TLM passthrough.
3. Solution servers - I have several that are external facing and terminate the TLS traffic passed along through the edge reverse proxy server. This is where all the work is done.

While not exposing all the details, one of my "solution servers" is a PlexMediaServer where I run a few automation tools for streamlining media gathering for presentation through my Plex server for our personal enjoyment.

I'm running the following setup on my PlexMediaServer

• PlexMediaServer - native to Ubuntu Linux
• Seerr - for requesting TV shows and/or Movies - we make the request, it determines what's available and when, then sends the actual management to:
• Radarr and/or Sonarr - Radarr handles movies and Sonarr handles TV series for tracking against various RSS feeds and Indexers. These two services then push the download request to:
• qBittorrent - which handles the actual downloading and seeding. Sonarr or Radarr monitor the download status and maintain the system of record for what's managed on my Plex server.

What makes this setup unique is... all of these services (Seerr, Sonarr, Radarr), except for Plex itself are running a Docker Containers. Each service is bound to specific ports (which are configurable, but need to be unique). In my case, I left them default.

On the PlexMediaServer - I installed NGINX and configured each sever block to capture incoming TLS requests for the respective service AND reverse proxied it to the respective docker container port - boom!

This is where TLM came into play. I installed a TLM agent tied to my demo/test portal in production. Had it scan local bindings and all certs. Found way more than I was expecting, but initially it found the wrong IP with single vhost cert that I'd bootstrapped with OpenSSL.

Another note: I had installed Tailscale some time back to access this server remote through my private VPN tool, Tailscale. Which worked "ok" - but resolution for my two primary users (Wife & MIL) to pick shows/movies - was clunky. Hence, adding these to public FQDNs.

First scan by TLM found a single cert bound to a 10.x network, which was where Tailscale lived/bound itself. I then declared specific IP address for each server block on NGINX (I have 3). TLM didn't see the specific IP server blocks.

WHERE THE RUBBER MEETS THE ROAD!
One shortcoming of setting up a new TLM agent is, SNI is not enabled. After first scan, if SNI is expected and not displayed, then it needs to be enabled and declared.

Some issues with SNI:

• If all FQDNs server blocks are bound to specific IP and it's the SAME IP, first scan will only show first vHost on the nginx.conf file and will fail to see the other FQDNs
• If server blocks are set to just listen on :443 - it will bind to first IP bound in stack, so best practice is consider declaring the IP in the server block. x.x.x.x:443 will insure the FQDN listens JUST on that IP.
• Once first scan is done, click into the TLM Agent and set SNI to enable. AND declare the specific FQDNs expected. Declare what's configured. TLM will not "discover" these.
• Another "oddity" if you have N+1 FQDNS, often time during automation configuration, the second or third FQDN may fail the last step in automation "test" - I've learned two things. Hit "Retry" once and if it fails again, test it manually and/or check the server block configuration to see if the "Digicert managed" cert was updated. If so, you may have to restart NGINX. My best guess is, TLM agent either skipped restarting NGINX or it failed getting the right cert. Dropping to CLI and manually restarting it will sometimes get it reset.

Now - in my case, all three FQDNs have quality public certificates issued and presenting the three services I have available. TLM is managing these and I've established automation for each of these certificates and will monitor.

First foray into installing and testing a Yubikey with 1Password = FAIL!

I've acquired (2) Yubikeys - one for primary use and another for backup in case the first one is lost, gets damaged or just stops working.

What is a Yubikey? -> It's a hardware token device that is designed for several functions. Onboard, it has the ability to:

1. Be a second factor during login on various accounts. Think authenticator app, but with a device. When you log into say your email account, enter a password, the second factor or (2FA) Two-Factor-Authentication - is the Yubikey.
2. Specifically built certificates can be added to the key in a specific partition designed to house certificates. This use case is for specific access for devices, networks, VPNs and/or anything that needs a unique identifier to validate the user is supposed to have access. Think - company badge that opens a door, but then you need a Yubikey with a unique identifier to define if this person can access this specific door. Certificates can be changed vs hard coded badges can not, which is why hardware tokens or Yubikeys are useful.
3. Passkeys - a newer authentication option that actually replaces passwords - it's a little more nuanced than 2FA or certificates and is stored on a specific area of the Yubikey. These are more tricky and frankly, problematic.

Now, lets get to the specific use case as a "newbie". All I wanted to do was setup my 1Password account to use a second authentication method or 2FA.

1. I have a Yubikey that i've setup (I think anyway) and established the PIN, PUK and Password to protect the key in case it physically gets out of my control. Yep, another password and PIN to remember. Sigh!
2. I have a 1Password account that does not have 2FA enabled. I should, but haven't set it up because I use 1Password as my "authenticator" app for everything else. So, to setup 1Password with 2FA it'd be a cyclical thing to sign into 1Password to create the authenticator code to, well, log into 1Password. I've tried and it kinda breaks - sorta. Another story, but suffice it to say, enabling 2FA for 1Password is tricky.

So, my thinking was, if I want to take advantage of 2FA for 1Password without setting up another authenticator app, a hardware token, AKA - Yubikey, would do the trick. That was my thinking anyway, but not as easy as it sounds.

To get started, I pulled up the 1Password documentation and quickly read through to get the general gist. Enable 2FA using a Security Key or Hardware Token, say yes to a few prompts and voila'.

I selected "Add a Security Key" and was prompted to approve my "passkey" - huh?! - that was my first indication that something was amiss because that's not exactly what I was expecting.

So - moving along, I hit save to the Passkey - which basically saved it back into 1Password - weird. (I actually failed at this point - because the documentation clearly said click on the little USB icon on the top right, NOT hit save) - but acting like a general user, the most obvious was to just hit save. Which - I did.

It just went south from there. The screen showed to "activate" my Yubikey and while the key was in the USB slot - nothing happened. Sigh!

Looking at my phone, I noticed a similar screen displaying and said to insert my Yubikey on my phone or near the top if it has NFC - which I pulled the Yubikey from my Macs USB slot, placed it near the top of the phone. Surely this would take.

Nope - it got stuck in some looping hell. A notification popped up saying, "Use Yubikey Authenticator App" - uh, yes please.

My iPhone launched the Yubikey Authenticator app and... well, nothing happened. More sighing insued!

Back on my Mac and on the Setup page for 1Passwords two-factor authentication page, I selected disable 2FA so as to not create a mess. Figured I'd start over and see if I missed something. Of course I did... the save the passkey to the little device icon, NOT 1Password.

STARTED OVER:

My second run was a little more promising, but it failed as well. The second time I selected the little USB stick icon.

... and was prompted with this message - YEAH!

My first thought was it should have prompted me for my PIN or PUK given I'd set it up with the Yubico Authenticator application and that maybe it'd just needed me to unlock it on the device.

I went back over to the Yubico Authenticator app and selected Passkey - attempted to unlock the FIDO2 section - what ever that is - and it failed to take my PIN. More sighing! I use a pretty standard PIN coding system - yeah, i know, not supposed to use same passwords/pins etc... but when you live in a login to many things world on a daily basis (I once tracked on any given day, I actually can log into, enter a pin/password or place my thumb on my biometric reader on my Mac - like over 300 times any given day - yikes) - So, I have to use something familiar.

No combination would work... sighing switched to cursing and GRRRRRR.... WTF!?

Considering I'd not used this device for anything yet, I noticed the "Factory reset" button. Maybe I'd slipped during the PIN entry phase and figured I'd just start over from scratch. More sighing.

This is where it went off the rails again.

I tried 3 or 4 times and continued to get this error.

I then popped over the Yubikeys support site, entered a support request, sent them my notes, included this screen shot and am waiting to hear back as to why this failed. I mean, factory reset means wipe the device and start over. But, apparently, when you select FIDO2, it fails.

Here's where I as a "casual" user who just wanted to use this hardware token device for 2FA on one of the most important aspects of my daily tools, my main password manager -> it's been an abismal failure. Yes, initially it was my fault for not reading for comprehension and/or failing to follow instructions, but once I got on track, it still failed all over the place.

While I'm fairly technical and specifically work in the PKI space - I work for the largest Certificate Authority on the planet, using a Yubikey is NOT for the faint of heart or the "casual" user.

I'm struggling and can't imagine a novice or casual user would have any better luck than I have with this device.

Stay tuned as I figure out how to use it for other applications.

So, this site is NOT intended to be my "documentation" per se, but I do hope to use it to document different test procedures, technology or the like.

What is my home lab? I do NOT plan to expose any of the details, like access, IP address, acct credentials or anything that would point a bad actor towards a path inside my home network - THAT would be both crazy and counterintuative to my own career focus, cybersecutiry professional.

My home lab basically consists of the following:

• Dell 650 server - 128gb RAM, 8CPUs and 8 drive slots for SSD drive storage.
• ProxMox - running on bare metal
• Lots of VMs - most for testing PKI automation, development, coding, new server technology, dockers etc...
• PiHole - a VM
• Plex - a VM

That's the foundation of my entire system.