Notes about user enrollment and certificates

When user starts enrollment we must give it JWT session token/cookie that marks this session as enrollment session for callsign X

Once user has delivered their auth code to the RASENMAEHER superuser and superuser has approved it their view changes to user instructions to download and install the device certificate. The device cert is loaded as binary from url /prefix/$callsign/client.pfx this URL must check the enrollment JWT matches the callsign.

RASENMAEHER api must store the users cert,key and pfx somewhere on local volume (sorted into subdirs by callsign, callsigns annot be re-used anyway) for future needs (like passing product [like TAK] integration APIs when requesting end-user instructions)

Below the installation instructions and link to pfx is a button to "check certicate" which connects to the mtls URL (browser will now ask user to choose the cert) and if the echo endpoint at mtls responds then we update both the JWT and local storage for the RASENMAEHER web ui to note that enrollment is complete after which the UI will always use the mtls url for all API calls.

sequenceDiagram
    participant FE as Frontend (used by Eeli)
    participant RM as RASENMAEHER
    participant TP as Tilauspalvelu

    TP ->> RM: Create code (tp signed JWT) for anon admin
    RM ->> TP: 
    TP ->> FE: Deliver code somehow
    FE ->> RM: Exchange code for session anon_admin JWT
    RM ->> FE: 
    FE ->> RM: Use anon_admin JWT to create admin user with callsign
    RM ->> FE: Code that can be exchanged for sessiont JWT
    FE ->> RM: Exchange code for session callsign JWT
    RM ->> FE: 
    FE ->> RM: Use JWT to fetch mTLS PFX
    RM ->> FE: 
    FE ->> RM: Use mTLS auth to create new enrollments, pools etc

The "first user admin" login token could in theory be delivered to another person or another device if the true first admin (that got a login token from TILAUSPALVELU) wishes to do so.

sequenceDiagram
    actor E as Eeli
    participant RM as RASENMAEHER+Frontend
    actor J as Janne

    E ->> RM: Create new pool (mTLS auth)
    RM ->> E: Invitecode
    E ->> J: Deliver invitecode
    J ->> RM: Use invitecode to start enrollment
    RM ->> J: Approvecode and JWT for checking status
    J ->> E: Deliver approvecode
    E ->> RM: Use code to approve enrollment
    J ->> RM: Use JWT to check if enrollment is ok
    RM ->> J: 
    J ->> RM: Use JWT to get PFX for mTLS certs
    RM ->> J: 
    J ->> RM: Use mTLS to get client configs, instructions etc
    

The issue names no files, tests, or existing entry points. Start by locating the enrollment, JWT/session, certificate storage, PFX download, and mTLS API paths described here. Done means the enrollment flow, approval state, certificate retrieval, local storage, and post-enrollment mTLS behavior are defined and verified end to end.