Solo v2 Security Key Won’t Register on Discourse: The CTAP2 Problem and How to Fix It

ByPriya Nair

The Short Answer

If your Solo v2 passes the webauthn.io test but fails to register on a Discourse forum, the culprit is almost certainly a CTAP2 negotiation mismatch. Your old Solo v1 worked because it behaved as a CTAP1/U2F device. The v2 leads with CTAP2 by default, and that exposes bugs in older server-side WebAuthn implementations — including some versions of Discourse.

Why the Solo v1 and v2 Behave So Differently

The Solo v1 was built primarily around FIDO U2F, also called CTAP1. Plug it in, touch the button, get a signed challenge back. Simple protocol, almost universally supported.

The Solo v2 is a full FIDO2 device. It supports resident keys (discoverable credentials), PIN-based user verification, and the newer CTAP2 protocol. That means more capability, but also more negotiation during registration — and more surface area for server-side libraries to handle poorly. CTAP2 support on forum software that isn’t aggressively maintained is still uneven.

The key responding with an LED color change tells you the hardware is fine and the browser is reaching it. The failure happens later, during the server’s processing of what the key returns.

What Goes Wrong on Discourse

Discourse uses a Ruby WebAuthn library to handle security key registration. Older or unpatched versions stumble on CTAP2-specific quirks in the Solo v2 — among them, credential IDs that are longer than some database field definitions were built to hold, and packed attestation formats that certain library versions can’t process. The user sees a generic failure message; the server log often shows something more specific like a field-length violation.

The Solo v2 GitHub repository has an open community discussion tracking sites where registration fails. Discourse instances appear on that list alongside Google, Microsoft, Nextcloud, GitLab, Dropbox, and a long tail of others. This isn’t the forum deliberately blocking new keys. It’s an unhandled edge case in whatever WebAuthn library version the server is running.

The Firefox Fix — Try This First

Open Firefox, go to about:config, find security.webauthn.ctap2, and toggle it to false. This makes Firefox fall back to CTAP1/U2F mode when talking to your key, stripping out the CTAP2 handshake that breaks on the server side.

Step by Step

  • Open Firefox and navigate to about:config
  • Accept the warning page
  • Search for security.webauthn.ctap2
  • Double-click the entry to toggle it to false
  • Return to the Discourse forum and try registering the key again
  • Flip the flag back to true afterward if you want CTAP2 on other sites

The trade-off is real: with CTAP2 disabled you lose PIN-enforced user verification and discoverable credentials for that session. For registering a second factor on a forum, CTAP1 is all you need anyway.

Mozilla’s own bug tracker documents cases where CTAP2 in Firefox has caused registration failures with specific authenticators, so this isn’t a hack — it’s a documented escape hatch.

Other Things Worth Trying

Switch browsers. Chromium-based browsers negotiate CTAP2 differently from Firefox, and the failure rate by site and key varies. Several users in the SoloKeys community discussions got past a stubborn site simply by moving from Chrome to Firefox or vice versa. Try both before giving up.

Try a different machine. USB HID stack differences at the OS level can interfere even when the key tests fine on webauthn.io. It shouldn’t matter. Sometimes it does.

Contact the forum administrators. If you can reach the Manjaro team, it’s worth a bug report. Discourse ships WebAuthn-related patches regularly, and running a current version is the real fix. The admin needs to check their installed version and whether relevant patches have been applied.

What Forum Admins Should Know

Default Discourse does not maintain an AAGUID allowlist. There is no configuration that intentionally blocks specific key models, so the Solo v2 is not being deliberately rejected. The failure is almost certainly a software version issue.

One specific failure mode: the Solo v2 generates credential IDs longer than some older schema definitions expected. That produces a database truncation or constraint error on the server. It is fixable with a schema migration and a library update — not a fundamental incompatibility.

Updating Discourse to a current release and ensuring the underlying WebAuthn gem is current is the clean resolution. The Discourse Meta forum has tracked WebAuthn-related fixes across several pull requests over the years.

The Solo v2’s Broader Compatibility Situation

The Discourse problem is one instance of a wider pattern. The same CTAP2-related registration failures have been documented on a long list of major services. As of mid-2026, the SoloKeys GitHub shows recent commits on the solo2 firmware, so the project appears to be alive — but progress has been slow, and the key’s real-world site compatibility has lagged behind its technical ambitions.

If you need a key that registers on everything without friction, a mainstream FIDO2 token from an established vendor is the pragmatic choice today. The Solo v2 is the right idea — open hardware, auditable Rust firmware, no proprietary secrets — but it carries more compatibility overhead than it should for day-to-day use.

Sources


Similar Posts