Admin console

The admin console lives at /admin on the Server. It is a Blazor web application read in English or Brazilian Portuguese, following the browser's Accept-Language and the language button in the app bar; two people can read the same deployment in different languages at the same moment. Certificate verdicts, audit event names, log lines and Signer's own messages stay English on every screen.

Everything the console shows is read from the platform's database, and everything it changes is written to the Audit Log with the signed-in account as the actor. The app bar is compact: one round button switches the language, and one account button holds the account and sign-out. The Server's version is shown in the navigation drawer. A signed-in person lands on the Dashboard, and so does a completed sign-in that had nowhere else to return to.

Signing in

An Admin Account is a local login: an e-mail address, a password of at least twelve characters, and a Second Factor from an authenticator app. There is no external identity provider and no reset mail. The first account is created from Admin:Bootstrap:* on a Server whose account table is empty; every later one is created by an Administrator on the Settings and users screen, who hands the initial password over in person.

On first sign-in an account enrolls its second factor: the console shows a QR code for the authenticator app, and then a set of Recovery Codes, shown once. A Recovery Code is a single-use substitute for the authenticator; a new set replaces the whole old one. Keep them where a lost phone cannot take them too.

Certificate Sign-In

A deployment can also let people sign in with an ICP-Brasil e-CPF read through Lacuna Web PKI. It is off by default and turned on in deployment configuration (Admin:CertificateSignIn:Enabled, with Admin:CertificateSignIn:WebPkiLicense naming the hostname people type; see Configuration). Where it is on, the login page and a page of its own, /admin/login/certificate, where the certificate is chosen, carry two links at the top, Password and Digital certificate, one for each way in. Only the certificate page carries the Web PKI component and licence; the login page carries neither:

• The login page remembers the way in. A password or certificate sign-in that is accepted writes a cookie, TrustBridge.SignInCredential, kept for a year and sent only to /admin/login, and a browser that last signed in with a certificate opens on the certificate page. A rejected or locked-out attempt opens the password form, and so does the Password link, whatever the browser last used.
• Only e-CPF certificates are listed, one row each: the holder, the issuer and the validity, with an A3 certificate or A1 certificate badge from the class the certificate's ICP-Brasil policy declares, which says nothing about where its key is kept. From six certificates up, the list has a search by name or issuer and a count. Expired certificates are listed under their own Expired heading, greyed and not choosable. An e-CNPJ, or a certificate with no CPF, is not offered. With none on the computer, the page says no certificate with a CPF was found; with only expired ones, it says so and asks for a token or card holding a valid e-CPF.
• Desktop browsers only. On a phone or a tablet the page says the feature is available on a computer only. Web PKI is served by the Server itself, so an air-gapped deployment works; a browser without the component is offered Install Web PKI.
• No password and no Second Factor step. The person picks the certificate, the token's own window asks for its PIN where there is one, and the certificate signs a single-use challenge. Only an ACTIVE verdict passes, against the Server's Trusted CAs and ICP-Brasil roots. An account that still has to enroll a Second Factor is led through enrollment first.
• It signs in the account whose Bound CPF the certificate claims. The binding is a CPF, never a certificate, so a renewed certificate keeps working. An Administrator sets it on the accounts screen (see Settings and users); nobody sets their own.
• Refusals before the account is known are told in full (component missing, certificate untrusted, expired, revoked, not an e-CPF). A certificate that matches no enabled account gets the same answer a wrong password does.
• It is rate-limited: ten challenges a minute per address (an IPv6 address counts by its /64), and at most eight certificate checks at once, past which the page asks to try again in a moment. A challenge request gives up after thirty seconds, and a challenge's lifetime is counted on the Server's clock, so a browser whose clock runs fast is not cut short. A failed certificate sign-in never counts towards the password lockout, and an account locked out by wrong passwords can still sign in with its certificate.

Passwords can be switched off with Admin:CertificateSignIn:Required. The login page then sends every visitor on to the certificate page, which no longer shows the two links, and an account without a Bound CPF cannot sign in at all, new accounts included. Like Admin:SecondFactor:Required it is deployment configuration only; Security has the checks to make before turning it on and the way back when nobody can sign in.

Roles

Role	May
Administrator	Read everything and change platform state: admit, revoke and remove machines, upload and offer Workstation Releases, register applications, issue keys, set an application's Signature Allowance and switch its Hash Signing, Per-Transaction PIN, Sessions without a PIN and REST PKI Core, import and disable Vault Certificates, add and remove Trusted CAs, change settings, manage accounts and set their Bound CPF, and make Test Signatures.
Auditor	Read everything, change nothing.

The Landing Page at / is what a browser sees before signing in. It says what the Server is and links onward; it shows no platform state. Where the deployment turned the public Test Signature on (TestSignature:Enabled), it also links to /test-signature; see Test Signature.

Monitoring

Dashboard

/admin/dashboard, the console's home and the first entry in the navigation drawer, readable by both roles. It shows the platform's Signing Activity: the documents signed and the digests signed by Hash Signing, always as two figures and never summed, and the Workstations that took part. The figures are settled: a background pass reads the Audit Log once a minute, five minutes behind, and the top of the page says the moment they are settled to. Nothing a signing call does is slowed or extended for the Dashboard's sake.

• Three tabs, Today, This month and Last 30 days, choose the window. The window is said as one sentence, such as Today so far, 11 documents and 538 digests were signed. 4 Workstations took part., with the other windows, since the installation among them, on a line beneath it. Two rows of bars show the last 30 days, one for documents and one for digests, the window's days in full colour and today hatched, since it is still counting. A day and a month start at midnight in Dashboard:TimeZone (UTC unless the deployment names an IANA zone).
• What needs you, beside the sentence, lists what is wrong now, each line with the screen that settles it: Signing Activity behind (it opens the Server log), the failures in the last 24 hours (the Audit Log), Workstations refused until they update, admitted Workstations not connected (the Workstations screen's Admitted, offline filter), admitted Workstations with a reader left failed and locked tokens, both from Workstation Reports, and certificates expiring within 30 days (the Certificate Registry). Nothing needs you. appears only after a pass that read all of it and is not stale.
• Four stage panels follow a signature over the window: Asked by, each Client Application's documents and digests; Waited for authorization, how long holders took to answer a Signing Authorization, a Workstation's stage only; Signed at, Workstations against the Certificate Vault, with how many admitted Workstations are connected now; and Outcome, the failures by event and code, the share of documents attempted that failed, and the busiest minute as a rate per second against the 10/s sustained target.
• How long signing takes, folded away beneath the panels, is the timing table: per document signed and per Hash Signing call, at a Workstation and at the Certificate Vault, each leg's p50 and p95. The figures are approximate, read from fixed ranges of durations. The Server's own measurements are kept apart from the machine's account of its own stages, which is shown and never relied on.
• Test Signatures are counted apart, in a line at the foot of the page, and stay out of every other figure.

Signing Activity is kept for as long as the installation is, so "since the installation" outlives the Audit Log's retention and can be larger than what the Audit Log still holds. On the first start of Server 1.17.0 or later it is back-filled from the whole Audit Log, and documents older than the oldest surviving audit row are recovered from the Signing Operations. Until that is done the page says Nothing is settled yet; where the Audit Log had already purged older rows, a note names the date digests are counted from. If Signing Activity stops advancing, What needs you and the status strip say where it stopped, and the Server log says why. A Test Signature still running holds the figures back on purpose, for as long as it runs.

The status strip

Every page carries a strip of counts under the app bar: workstations online, workstations that need an update to connect, active sessions, documents and digests signed in the last 24 settled hours, failures in the last 24 hours, and certificates expiring within 30 days. Each chip opens the screen it summarizes, already filtered: the online machines, the machines that need an update, the live sessions, the Dashboard, the Audit Log's failures since the count started (a closable Since … chip on the Audit Log), and the certificates expiring. The signed chip reads the Dashboard's Signing Activity, so it counts documents and digests actually signed, and its tooltip names the moment it is settled to. Before Signing Activity is first counted it reads Signing Activity not settled yet, and when it has stopped a chip reads Signing Activity stopped at … and opens the Dashboard. When the database cannot be reached the chips dim and say their numbers are stale.

Audit Log

/admin/audit. The append-only record of platform events: API access, session and signing lifecycle, Hash Signing and Signing Authorizations, workstation and PIN events, fleet updates, callback deliveries, Test Signatures, admin actions and sign-ins. One row per event with the moment (UTC), the event name, the actor, the subject and the outcome, plus details; a row about a Company's session or certificate also shows its CNPJ. PINs, PIN Proofs, document content and signature bytes never appear.

A few details are worth knowing. Every signing outcome row (signing.completed or -failed, hash-signing.completed or -failed) carries the call's legs as timing and, where the machine gave one, its own account of its stages as machineReported, whether or not the deployment sends the Server-Timing header. Every row a document's signing run writes names the engine that built it in documentSigner, and session.created says whether a PIN was proven at creation (pin: "proven" or "none"). The Client Applications screen writes admin.application-signature-allowance-changed (the figure before and after), admin.application-document-signer-changed (the engine before and after), and admin.application-session-pin-waived or -required. A removal writes admin.workstation-removed, naming the machine in full: its hostname, key thumbprint, when it was first admitted, the state it was removed from and whether it was connected.

An api.call row says which error its caller got (Server 1.24.0). It keeps the Error Code the call was answered with in its details as errorCode, and the Event cell shows it after the HTTP status, as in GET /v1/certificates/info 401 SESSION_EXPIRED. The status alone does not say which: UNAUTHORIZED and SESSION_EXPIRED are both 401s, and SERVER_BUSY shares its 429 with TOO_MANY_PIN_ATTEMPTS. Only the code is kept, never the error's message or details, and it stays English. A call answered without an error envelope carries none, and a row written before 1.24.0 reads as it did.

A refusal a machine could not route to a Tray App says why. A signing.authorization-refused row whose reason is NO_TRAY carries detail (Server 1.22.0, from Workstation 1.9.0): which of the machine's reasons it was, the Windows session at the console, the sessions a Tray App was attached in, and the Tray's build. A pin.prompt-answered row whose answer is Undeliverable carries the same detail for a session-start PIN prompt (Server 1.23.0, from Workstation 1.10.0). detail is null on every other reason, and from an older machine. The machine's Events tab says each reason in words; Troubleshooting lists them.

Filters: an actor (display name or exact id), a CPF, a CNPJ, a session id, an API key (one key's own trail, refused calls included), a Workstation id (one machine's rows, of every event type), an event type, an outcome, a correlation id (one request's whole trail), and a time window. The Workstation id field (Server 1.23.0) names the machine by its hostname, says A removed workstation. Its events stay on the trail. while the trail still holds its removal, or No workstation has this id.; a removed machine's rows keep its id and are still found. A workstationId= link fills it, and the machine's Events tab links there. Other screens link into the trail through a Trail column, so a Signing Session or an API key row is one click from its history. A row the database refused was written to the Server log at Critical instead, and the console raises an alert when that has happened.

Retention is Audit:RetentionDays (365 by default), one of the seven settings an Administrator can change on the Settings and users screen. The daily purge never deletes a row the Dashboard's Signing Activity has not counted yet, so it waits for the first back-fill and, while Signing Activity is behind, keeps rows past the retention (Operations).

Fleet

Workstations

/admin/fleet. Every admitted machine: its status, hostname, Console Account, Workstation Service version, Updates, its standing with this Server's Trusted CAs, number of certificates, its Report, and when it was last seen. An online row reads connected and how long ago the current connection was made, rather than a last-seen time. The Console Account column took the operating system's place in Server 1.23.0; the operating system is in the detail panel's header.

The filters are a row of chips, each with how many machines it holds, counted with the search and any Workstation Reports row applied, so a chip lists the number it shows: All, Online, Offline (Revoked machines included), Admitted, offline, Update required, With refusals (24h), Console Account, no Tray, and the two Workstation Report filters, Reader failed and Token locked. A link selects one with ?show=: online, admitted-offline (what the Dashboard's not-connected line opens), update-required, refusals, console-no-tray, reader-failed or token-locked. A ?workstation=<id> link opens one machine's panel over the whole fleet; the Signing Sessions and Signing Operations screens link a machine there.

The search matches the hostname, the Console Account, and the holders of the certificates the Certificate Registry holds on the machine: the holder's name, an e-CNPJ's Company name, the CPF and an e-CNPJ's CNPJ, typed with or without dots, dashes and slash. A machine is found from the caller's Windows login, their name or their CPF. The rest of a certificate's subject, such as its issuer, finds nothing.

The Console Account column says who is at each machine's console, as its last Workstation Report said: the Windows account signed in at the physical console, as its DOMAIN\user name, or its SID where the name does not resolve. Beside the account is the worst thing wrong with the Tray App there. The cell is never blank:

Cell	Meaning
An account	Somebody is signed in at the console, unlocked, with a Tray App of the service's version running there.
An account · no Tray	Somebody is signed in and no Tray App runs in that session, so nothing there can show a PIN prompt. Per-transaction signing calls and session-start PIN prompts sent to this machine are refused until one does.
An account · Tray and a version	The Tray App runs another version than the Workstation Service.
An account · locked	The console session is locked.
Nobody at the console	Nobody is signed in at the console. 1 other session with a Tray beneath it means a holder on Remote Desktop, or one switched away from the console, where no PIN prompt reaches.
Needs Workstation 1.10.0	The machine runs an earlier release, which does not report its console.
Not reported	The machine's reporting is off, or it has not reported since it began running the version it runs now.

An offline machine shows the console it last reported, with reported and how long ago, and so does a machine whose last report could not read its console. A Revoked machine keeps its console; a removed machine's goes with its row. A change of console writes nothing to the Audit Log.

Console Account, no Tray lists the online Admitted machines whose last report has somebody signed in at the console and no Tray App there: the machines that will refuse their holder, found before anyone calls. An offline machine, or one whose last report could not read its console, is not counted, whatever its cell shows. Nobody at the console, reporting off and a release too old to report its console are not in it either.

N refusals (24h) in the status cell counts the machine's Workstation Refusals in the last 24 hours, by the Server's clock, that were a problem with the machine: a Signing Authorization it refused, or a session-start PIN prompt it could not show, that timed out or whose PIN did not match. A holder declining, a Client Application giving up the wait and a call authorized after its session had ended are somebody's choice and are left out; a wrong PIN counts, since a few in a row lock a token. With refusals (24h) lists the Admitted machines that wear the chip; a Revoked machine keeps its chip and is left out of the filter. The count does not reach the Dashboard's What needs you.

A machine's panel shows its hostname, status and operating system in the header, and the Administrator's two actions on a row of their own beneath it. Then an At the console section, its protocol, when it was first seen, its key fingerprint and posture, its offer and last update, its Workstation Report, and three tabs: Certificates, Sessions and Events.

• At the console names the Console Account with its SID beside it, whether the session is Locked or Unlocked, the Tray App at the console (Running and its version, noted when it is older than the service's, or Not running), and the Other sessions with a Tray, counted without their accounts. A machine that shows none says why: its reporting is off, its release is too old to report a console, or it has not reported one since it began running its version.
• The Events tab says each Workstation Refusal in words: a refused Signing Authorization by its reason, a NO_TRAY by the cause the machine named, and a session-start PIN prompt answered Undeliverable, TimedOut or Mismatch as a refused prompt. Where the holder can fix it, What to ask: follows; a decline or a Client Application that stopped waiting is marked Somebody's choice, not a problem with the machine. The raw code and the session are beneath, small. A reason this Server does not know is shown as its code, and counts as a problem.
• Refusals only, a toggle on the tab, lists the machine's latest refusals instead of its latest events, so connects cannot push them out. It is on when the panel opens on a machine with a problem refusal in the last 24 hours. See everything in the Audit log, beside it, opens the Audit Log filtered to the machine.
• Each disconnect in the Events tab names why the connection ended (revoked, removed, returned-to-queue, server-stopping, timed-out, error or closed).

An Administrator has two actions on the panel:

• Revoke machine is the security control: the machine stops authenticating at once, sessions bound to it can no longer sign, and its request to join is refused rather than returned to the queue for as long as its row stands on the fleet. It does not need the machine's cooperation, and it is the right response to a machine that was lost, stolen or compromised. A machine goes back to the admission queue only by asking from its own Tray App.
• Remove machine is housekeeping, for a machine that was reimaged, renamed or retired, or admitted by mistake. See Removing a machine.

Update required marks a machine that speaks a protocol older than the oldest this Server accepts. Its handshake is refused until a current release is installed on it by hand or by Group Policy. On Server 1.15.0 and later that is every machine on Workstation 1.4.x or older. A machine on Workstation 1.5.0 still connects and serves every session, but it is never chosen for a session whose Client Application has Per-Transaction PIN on until it runs Workstation 1.6.0; offer it that release.

Offering a release. Select machines and use Offer release…, or Deliver to all not yet updated… for every admitted machine below a release, offline ones included (they get the offer when they connect). That second one is a one-time selection: a machine admitted later is not included, and any machine can be unticked before confirming. A release reaches only an admitted machine below it, that can take updates from the Server, whose Publisher Pin lists the release's signer and whose Group Policy leaves updates on; the dialog lists the others with the reason. An offer replaces whatever the machine was offered before. Withdraw offer takes it back from the selected machines; a machine that already installed it stays on it. Offering a machine the release it already holds offered is how a failed install is tried again.

The Updates column reads:

Row	Meaning
Offered and a version	The machine holds an offer it has not finished acting on.
Updated to a version	Its last update installed.
Update to … failed	The install failed. The panel shows msiexec's exit status and the stretch of its log leading up to the failure.
Update to … refused	The machine refused the package, naming the check that failed.
Updates disabled by policy	The machine's Group Policy turns updates from the Server off. Offers leave it out; update it the way it was installed.
Needs a manual update	Its version cannot take updates from the Server, or it does not know the signing certificate of any release this Server holds above it. Install the release by hand or by Group Policy.

Every offer and withdrawal is an admin.workstation-release-offered or admin.workstation-release-withdrawn row, and each outcome a machine reports is one workstation.update-installed, workstation.update-failed or workstation.update-refused row. Workstation installation says what a machine does with an offer.

The trust-standing column reads one of five words per machine:

Standing	Meaning
Up to date	The machine holds the Trusted CA set currently in force.
Behind	The machine still holds a previous set. It catches up within seconds while connected, or at its next connect.
Refusing	The machine is configured not to take the Server's set (UseServerTrustedCas off).
Needs update	The machine last announced a protocol too old to ask for the set (Workstation 1.0.x). This Server refuses its handshake, so it stays this way until a current release is installed on it.
Not reported	The machine has not said which set it holds.

The Report column shows the worst thing the machine's last Workstation Report said: Reader failed, Token locked, N kinds of error (24h) (error templates last seen in the past day) or Not reported. Not reported is never a clean bill: it is a machine on a release before Workstation 1.8.0, one whose deployment turned reporting off, or one whose last report was sent by another version than the one it runs now. The panel's Workstation Report section says when the report was received and lists what it holds: the PKI licence as the machine holds it, its .NET runtime, its A3 detection, Insertion Prompt and reader-restart switches, any readers left failed, each token it sees (vendor, model, serial, the holders' CPFs and how close its PIN is to locking), each middleware with its version and whether it loaded, and its errors grouped by template, each with a count, when it was first and last seen, and its latest values and exception. Error templates are the machine's own log lines, in English on either language. A revoked machine keeps its last report on the panel.

Removing a machine

Remove machine, beside Revoke machine on the detail panel's row of actions, makes the Server forget an admitted or revoked machine. Only an Administrator has it, behind a confirmation that asks for the machine's hostname typed in full (in any case). What goes and what stays:

• It goes: the machine's row, its Certificate Registry entries, its Workstation Report and its failed PIN proofs. One admin.workstation-removed row in the Audit Log names it in full.
• It stays: its signing history. Signing Sessions, Signing Operations and Audit Log rows keep the machine's id, and the session and operation lists name it removed workstation and the first group of that id, which the removal's audit row maps back to a hostname for as long as that row is kept. The Dashboard's Signing Activity reads the same before and after. A session still live on the machine is neither ended nor charged: a sign under it is answered 422 WORKSTATION_OFFLINE with details workstation removed until it expires.
• A connected machine is hung up with the reason removed, and the confirmation says so first. If it is still installed, its reconnect is refused as an unknown key and its request for admission arrives in the queue as a new machine, under a new id, that has to be admitted again.
• A revoked machine's refusal goes with its row, and the confirmation warns so: the same key could ask again and be admitted. Leave a lost or compromised machine revoked.

The removal applies only to the state the panel showed: a machine admitted, revoked or sent back to the queue meanwhile is left as it is, and the panel says it changed. Remove is also offered on a row of the admission queue for a machine that was admitted once and sent back to it.

Admission queue

/admin/admission. Machines that have asked to join and are waiting for a person. Each row shows the hostname, operating system, versions, the key's posture (Hardware key or Software key) and its fingerprint, and how long it has been waiting. Admit lets it in; on its next reconnect the machine connects and moves to the Workstations screen.

The screen says above the table what admitting means: with no out-of-band channel to check a fingerprint against, admitting is a decision rather than a verification. Read the hostname and the posture, and if the deployment sets Admission:RequireHardwareBackedKeys, the Admit control refuses a software-keyed machine and the row says why. A request nobody acts on lapses after Admission:PendingExpiry counted from the machine's last request.

A machine that was admitted once and sent back to the queue never lapses, so its row also offers Remove, behind the same typed confirmation as on the fleet screen. A request from a machine nobody ever admitted is offered no Remove: it lapses on its own.

Workstation Reports

/admin/workstation-reports, beside the Workstations screen. A machine on Workstation 1.8.0 or later tells the Server about its own condition whenever it connects and whenever that changes, and the Server keeps the last report of each machine. This screen shows what the Admitted machines' last reports have in common, Revoked machines left out, in three tables: Errors by template, Tokens by vendor and model (with the locked ones counted) and Middleware by name and version. Each row counts the machines and opens the Workstations screen on just those machines, under a closable chip naming the row. Both roles read it.

A report is never written to the Audit Log. Error groups no report has added to for WorkstationReports:ErrorRetentionDays (30 by default) are deleted by a daily sweep. A deployment can turn reporting off per machine; such a machine reads Not reported, and the Server forgets what it held for it.

Workstation Releases

/admin/workstation-releases. The Workstation packages this Server holds for the fleet to take, one row per version: the version, who signed it, the package size, when it was uploaded and how many machines it is offered to. Below the table the screen says how many releases are stored and how much database space they take.

Upload a release (Administrators): choose a signed Workstation MSI of up to 256 MB and it is read as it arrives. The Server takes the version, the protocol the package speaks and its signer out of the file, so nothing is typed. It is refused by name, with nothing stored, when it is:

• not a Windows Installer package;
• unsigned, or its signature cannot be read;
• signed by a certificate the Publisher Pin compiled into this Server does not list;
• a version that is not three numbers;
• a package that declares no protocol, which every Workstation release before 1.3.0 is;
• a protocol outside this Server's window (Server 1.15.0 and later accept 5 and 6, which is Workstation 1.5.0 and later), and the refusal says to upgrade the Server first when the package is newer;
• a version already stored (delete it first to replace it);
• larger than 256 MB, or the Server cannot write its scratch directory /tmp/trustbridge-releases.

Each refusal is an admin.workstation-release-uploaded failure in the Audit Log. The upload is one request: on App Service it has to finish within the front end's request timeout (about four minutes), and a reverse proxy in front of the Server needs a body limit above 256 MB.

Delete removes the package from the database and the Server's copy with it. A release offered to any machine cannot be deleted until the offers are withdrawn; machines that installed it keep it. On a small database, such as Azure SQL Basic, a delete can take a few minutes (it has a ten-minute budget, as an upload does); the screen says when it has started, and a database failure gets its own error message. Withdraw from all takes one release back from every machine it is offered to. An Auditor sees the whole screen and changes nothing.

Certificate Registry

/admin/certificates. Every Workstation Certificate the fleet has announced: the holder and CPF, the CNPJ for an e-CNPJ, the certificate (subject, issuer, thumbprint), which workstations hold it with each one's online state and last-seen time, the verdict, the validity and when it was last checked. For an e-CNPJ the CPF is that of the person who holds it for the Company, labelled Holder for the Company. Search by CPF, CNPJ, holder, thumbprint or workstation; filter by status or by Expiring within 30 days. Entries are last-known state; a disconnected workstation's certificates stay listed and flagged offline.

An UNTRUSTED row offers Trust the issuer: the Server walks the certificate's chain, names the authority it could not reach a root through, and offers to add it as a Trusted CA. A machine on an older Workstation Service sends no encoding, so its rows cannot offer this.

Signing Sessions

/admin/sessions. Every Signing Session: the holder, the CNPJ when the session is for a Company, the Client Application that created it, what it is bound to (a certificate on a named workstation, or the vault), its state (active, expired, deactivated, replaced, exhausted, stranded), when it was created and when it expires, the number of documents signed under it and, where its Client Application had a Signature Allowance when the session was created, the spend against it. Each row links to its trail. A session created under Per-Transaction PIN says so under its id: Per-Transaction PIN, typed at the workstation or Per-Transaction PIN, sent by the client. Since Server 1.23.0:

• The holder is named as the certificate names them, read as the Signing Operations screen reads a run's, with the CPF beneath; a Company's session keeps Holder for the Company. The Client Application column names the application by the session.created row its session left.
• The bound machine is a link that opens its panel on the Workstations screen, with its Console Account cell beneath it. A Vault Certificate's session has neither. A session bound to a machine that was since removed reads removed workstation and the first group of the machine's id.
• A live session on a machine with a problem Workstation Refusal in the last 24 hours is tinted, and says how many under its Live chip, such as 1 refusal on the machine (24h). A decline, an abandoned call, or a call the holder authorized after its session had ended does not count.
• The filters are counts that act as filters, each with how many rows it lists, the search applied: All, Live, Live with refusals (24h), Ended and Refused creations (24h). ?show=live selects Live, which is what the status strip's active-sessions chip opens, and ?show=refused selects Refused creations (24h).
• The search matches the session id, the holder's name, CPF and CNPJ (punctuated or not), the Client Application, the thumbprint and the machine's hostname.

Refused creations (24h) lists, in place of the sessions, every POST /v1/sessions refused in the last 24 hours by the Server's clock: the "my session won't start" call, one click away. Each row reads When, the holder by name with the CPF beneath, the Client Application, and Why in words with the code small, such as No PIN was available to compare the one sent against. Under Workstations prompted it lists every machine the request asked for the PIN, each with its answer in the words the Events tab uses and a link to its panel, or says No machine was prompted for the PIN. A machine before Workstation 1.10.0 reads its bare Undeliverable, and a removed machine keeps the hostname it answered under and links nowhere. The newest 200 are listed, and the screen says when there were more; the rest are in the Audit Log.

Signing Operations

/admin/operations. One row per document submitted for signing: the document name, the holder, where it ran (a workstation, the vault, or a removed workstation and the first group of its id), when it was submitted, its state (Pending, Completed, Failed), and its trail. A document signed with REST PKI Core records its own stages, rest-pki-core-prepare and rest-pki-core-complete, where the Signer's path records prepare and complete. A run interrupted by a Server restart is ended by a sweep as Failed with RUN_STRANDED. A refused signing call is never on this screen: it creates no Signing Operation, and the machine's Events tab and the Audit Log are where it is. Since Server 1.23.0 the screen says what went wrong with a run:

• The filters are counts that act as filters: All, Pending, Failed (24h) and Completed (24h), by the Server's clock. With Failed (24h) picked, a row of chips groups the failures by cause, each with its count, so three PIN_NOT_AVAILABLEs that were a locked token are told from a PIN never entered. Unless a search narrows them, the 24-hour counts and the causes count every run that ended in the window, beyond the newest 200 ended runs the table lists, and a table that lists fewer than its count says so.
• A failure reads in words, with What to ask: where the holder can act, such as The token rejected the PIN. The code, the cause and the stage stay beside it, small.
• It says whether the holder's token signed. From the signed stage onward it did, and a signed document may exist at the signature service. A run that stopped before the token was asked, or whose holder answered at hash-sign that it did not sign, reads The holder's token did not sign: nothing was spent. One that ran out of time, lost its machine or lost its client at hash-sign reads as not known.
• A run pending longer than a live run can last (twice Signing:RequestBudget plus Signing:SignerCancelBudget) is tinted and says what it is waiting on, such as Still pending: waiting on the holder's token to sign.
• A failed run records what the Workstation answered beside its code (the FailureCause column), because a PIN not cached, a PIN the token rejected, a locked token and an authorization the machine no longer held all end as PIN_NOT_AVAILABLE. A run that failed before Server 1.23.0 reads by its code alone.
• The holder reads by name, from the certificate, with the CPF beneath. The machine links to its panel on the Workstations screen and carries its Console Account cell.
• A Client Application filter sits beside the search, which matches the document, the holder, the CPF, the Client Application, the workstation and the correlation id. The correlation id a client can quote is in the tooltip of the row's trail button.

Access

Client Applications

/admin/applications. The external systems that call the SignSession Contract, each with its API keys. Register an application with a name (what the Audit Log will call it) and a description, then Issue key: give the key a name saying where it is deployed and an optional expiry date. The key's value is shown once, in a dialog, and only its SHA-256 is stored; nothing recovers it afterwards. Each key row shows its age, last use, and its own trail.

A key can be revoked (the next request bearing it is refused, permanently) and its expiry edited. An application can be disabled, which refuses every one of its keys at once while keeping them, and enabled again. Missing, unknown, revoked, expired and disabled-application keys are all rejected identically on the wire with UNAUTHORIZED.

Each application's card carries its Signature Allowance and four switches, all of them per application and never per key. The switches are off for every application until an Administrator turns them on; an Auditor sees them read-only.

• Signature Allowance: how many signing calls each Signing Session the application creates may make. The card says the figure, or that there is none, in which case a session is bounded by its idle window alone. An Administrator changes it in the Signature Allowance dialog, in Signing calls per session; leaving the field empty clears it, and a figure below 1 is refused. Every session the application creates afterwards is granted that figure and ends as Exhausted after that many signing calls, whichever of the application's keys makes them. A session that already exists keeps the allowance it was granted, so lowering a figure ends nothing mid-batch. A Test Signature and a Hash Signing call get the allowance of the application whose key created the session. Audited as admin.application-signature-allowance-changed. This replaces Sessions:SignatureAllowance, which Server 1.17.0 and later no longer read (Configuration).
• Hash Signing: whether the application may call POST /v1/signatures/hashes and have a holder's key sign digests it computed itself. Nothing inspects what they are digests of, so grant it only to an integrator that assembles its own signed structures, and the console asks for confirmation. Revoking it refuses the application's next Hash Signing call and leaves its document signing and its sessions untouched. Audited as admin.application-hash-signing-granted and admin.application-hash-signing-revoked.
• Per-Transaction PIN: whether every signing call under a session the application creates needs the holder's PIN for that call, typed at the holder's Tray App, or sent by the application for a Vault Certificate (REST API). It applies to sessions created after the change, and the console asks for confirmation before turning it on. Turn it on only once the Fleet screen shows the application's holders' machines on Workstation 1.6.0: a holder whose machines are all older is answered WORKSTATION_OFFLINE. Audited as admin.application-transaction-pin-enabled and admin.application-transaction-pin-disabled.
• Sessions without a PIN: offered only while Per-Transaction PIN is on. It lets the application create a Signing Session without the holder's PIN, which binds only where exactly one certificate could serve it; every signing call under it still needs the PIN (REST API). The console asks for confirmation before turning it on, saying what it grants: any API key of the application can then create a session for any CPF with a certificate, read that certificate and replace that CPF's active session, without the PIN. It applies to sessions created after the change. Turning Per-Transaction PIN off turns this off with it, after a confirmation of its own. Audited as admin.application-session-pin-waived and admin.application-session-pin-required; turning Per-Transaction PIN off writes the -required row beside its own.
• Sign documents with REST PKI Core: whether the application's documents are signed by REST PKI Core, Lacuna's PDF signing service, instead of the Signer. With it on, REST PKI Core prepares and completes every document the application's keys sign, around the one signature the holder's key makes, keeps the signed documents, and may mark their pages according to its subscription's settings; the card says so. Nothing changes on the wire, and Hash Signing is not affected. The switch takes effect from the application's next signing call, under whichever session it signs. On a Server whose deployment configured no RestPkiCore section it is refused, saying REST PKI Core is not configured; switching back to the Signer is never refused, and a document either engine signed stays fetchable after a switch. What has to be set up first, on this Server and on REST PKI Core's side, is on Configuration. Audited as admin.application-document-signer-changed, naming the engine before and after.

Vault Certificates

/admin/vault. Present only on a Server with Vault:Enabled; otherwise the screen says the vault is off and names the setting. Lists every certificate the Server holds itself: the holder and CPF, the CNPJ for an e-CNPJ, the certificate, its verdict, validity, when it was imported, and whether it is in use. The Key Ring Protector warning is always in view; the warning about the import password sits behind About the import password.

Import a PFX: one certificate and its private key per file, an ICP-Brasil e-CPF or e-CNPJ, with the file's password. An e-CNPJ must name a valid CNPJ and a valid CPF for the person who holds it. The import proves the bag can be opened by the reader that will sign with it; a file whose key is shrouded under pkcs5PBES2 is refused with a message naming the legacy re-export (openssl pkcs12 -export -legacy). The password is used once and never stored: a client application supplies it as the pin at every session creation. A Server whose PKI licence was refused refuses every import.

Two actions per certificate. Disable takes it out of use: it creates no session and signs nothing until enabled again, while the file, its key and its history stay. Delete destroys the private key material and cannot be undone; the confirmation asks you to type the CPF. Neither reaches a live session already bound to the certificate, except that the secret retained for that session is dropped at once, so its next signature is refused. There is no export or download path anywhere.

Trusted CAs

/admin/trusted-cas. The certification authorities an Administrator told this Server to trust, on top of the ICP-Brasil roots the deployment already vouches for. Each row: its kind (Root or Intermediate), the authority, its certificate and validity, what depends on it, and since when it is trusted.

Trust a certification authority: upload one file, DER, PEM or a PKCS#7 bundle, decided by what is in it rather than by its name. A file may carry a whole chain, and every authority in it is offered. A holder's certificate is also accepted: the Server reads its issuer, follows the certificate's own caIssuers pointers over the web where it has to (at most four fetches), and offers what it found, flagging an authority fetched from a URL the untrusted certificate itself named as one whose fingerprint to check especially carefully. Nothing is trusted until you confirm the offer.

Adding takes effect on the running Server with no restart and reaches every connected admitted machine within seconds. Stop trusting one can turn Workstation Certificates and Vault Certificates UNTRUSTED, and where Certificate Sign-In is on it can refuse administrators' sign-ins, so the row and the confirmation count what depends on it first:

• In the vault: exact once every Vault Certificate has a recorded chain, which the hourly revalidation and every import write. Until then, and for rows whose chain never built, the count reads at least. Expired certificates are left out.
• On machines: always at least, matched by issuer name.
• Among admin accounts: at least, counting accounts that last signed in with a certificate from this authority. Shown only where Certificate Sign-In is on or somebody still holds a Bound CPF. It cannot see a binding that has not signed in yet, or the next certificate a person will present.

Nothing blocks a removal. A machine that is offline keeps trusting a removed CA until it reconnects. Removed rows are kept rather than erased so the Audit Log can name them.

System

Settings and users

/admin/settings. Two things.

Platform settings: the seven keys an Administrator can override at runtime, each with a help text and the deployed default beside it. A saved value beats the deployment's configuration and takes effect without a restart; Restore the deployed defaults clears the overrides.

Setting	Default
Default session window	1 h
Maximum session window	24 h
Tray prompt timeout	60 s
PIN failures before lockout	5
PIN lockout window	15 min
Workstation reconnect grace	15 s
Audit retention (days)	365

The two PIN figures also set the Failed-Proof Budgets: how many PIN Proofs one workstation may fail for one CPF in the window, and how many passwords the Certificate Vault may try for one CPF that open nothing (Configuration).

Some switches are deliberately not here: Admin:SecondFactor:Required, the Admin:CertificateSignIn:* keys and Vault:Enabled. They are deployment configuration, because a switch that weakens the console's protection or turns on server-held private keys must not be reachable from inside the console.

Admin accounts: every account with its role, access state, last sign-in and second-factor enrollment. An Administrator can create an account, set a password (their existing sessions end within five minutes), make an account an Auditor or an Administrator, disable it (kept, because the Audit Log attributes its past actions to it) and enable it again, Clear lockout on an account locked out by failed sign-ins, and clear somebody's second factor, which also invalidates their Recovery Codes and leaves them to enroll again at their next sign-in. No one can read or set another person's second factor.

Where Certificate Sign-In is on, or any account still holds a binding, the table also has a Bound CPF column showing the full CPF to both roles. An Administrator sets it with Set Bound CPF (or Replace Bound CPF) on another account's row, or in the new-account form, and removes it with Clear Bound CPF:

• Never on their own row, for setting, replacing and clearing alike. A deployment that switches passwords off therefore needs at least two Administrators.
• Setting needs Certificate Sign-In turned on; clearing is always allowed.
• The check digits must hold (dots and a dash are accepted), and a CPF another account holds is refused, naming that account.
• Replacing or clearing ends that person's open sessions within five minutes. A first setting ends nothing.

Each change is an admin.account-bound-cpf-set or admin.account-bound-cpf-cleared row carrying the CPF. Whoever holds a Bound CPF can be signed in by any trusted e-CPF that claims it, with no password, so the person it belongs to sees on their own account page who set it and when.

Test Signature

/admin/test-signature, under System. An Administrator makes a real signature end to end: types a CPF, its PIN, optionally a CNPJ, a Client Application's API key, optionally a fallback e-mail address, a timeout and how many documents, and gets back the certificate's public details and a signed one-page PDF, or the step that failed (session, certificate, document, signature, Signer, REST PKI Core, timeout or loopback). It is the quickest proof that a deployment signs. The run goes through the Server's own contract with the typed key, as an integrator's call would, so it signs with the engine that key's Client Application uses and gets that application's Signature Allowance, and it replaces any Signing Session already active for that CPF and CNPJ. The PIN may be left empty where the key's application creates its sessions without a PIN and the holder's one certificate is on a workstation, where the holder approves the signature at the Tray App; a certificate in the Certificate Vault always needs it. The page is there whatever TestSignature:Enabled says, and its runs name the Administrator as the actor in the Audit Log (test_signature.completed, test_signature.failed or test_signature.refused). An Auditor sees whether the public page is on, and no form.

Since Server 1.23.0 and 1.24.0:

• A run may sign a batch. Documents takes 1 to 50, or Signing:MaxBatchItems where that is lower, and more than one is signed as numbered copies in one POST /v1/signatures/batch call. The page says Signed N of M documents, offers Download the signed documents (ZIP) (test-signatures.zip), and names each document that did not sign by the step it failed at. A timeout that runs out while the signed copies are fetched keeps the ones already fetched. A batch's test_signature.* row records how many documents were asked for, and of a completed one how many signed. A run of one document is the single call it always was.
• The page keeps what was typed. The answer writes every field back into the form, the API key and the PIN included, and Sign again shows the filled form behind the result, so a second run is one press. The answered page is not cached by the browser; on a shared machine, a demonstration ends by closing the tab. The Server still logs neither the key nor the PIN, and forgets both once the page is written.
• A failure at the signature step says why, by the contract's code (Server 1.24.0), in a sentence after the step's own, with Contract code: and Contract's answer: beside it, in English as the contract sends them. Troubleshooting lists them.

The public page at /test-signature is the same form for anyone who can reach the Server, and exists only where the deployment turned it on. On Docker, both need a plain-HTTP loopback listener and an AllowedHosts that admits it; see Configuration.

Server log

/admin/logs. The newest lines of one UTC day of the Server's own log, read from the rolling file under Logging:File:Directory, filtered by level and text: when, level, source category, message, and the correlation id that leads to the matching Audit Log rows. A convenience for whoever is at the console, not a record: the console output is the record, and the file is deleted after Logging:File:RetainedDays. On a deployment that turned the file off, the screen says so and names the key.

Your account

/admin/account. The one credential on the platform a person manages themselves: change the password, replace the authenticator when changing device, and mint a fresh set of Recovery Codes, with a Recovery Code accepted in place of the authenticator for that action.

Where Certificate Sign-In applies, a Certificate Sign-In card shows the account's Bound CPF read-only, with who set it and when, or says that none is bound and that another Administrator sets it.

Banners

Three conditions put something on every page of the console for as long as they last:

• This platform trusts the Lacuna test CAs: Certificates:Validation:UseLacunaTestPki is on, a development switch that makes anybody's sample certificate sign as ACTIVE.
• This Server's PKI licence was refused: no Vault Certificate can sign, and no workstation will once it restarts: the PKI SDK refused Certificates:Validation:License at start. It is the licence every admitted machine is handed, so until it is renewed and the Server restarted no Vault Certificate signs, and no workstation signs once its Workstation Service restarts. A machine already running keeps signing until then only if it still holds an earlier licence the SDK accepts, as after a renewal typed wrong. The start-up log says why it was refused.
• Audit writes are falling back to the Server log: an audit row could not reach the database. The alert sits in the status strip, counts the failures since the Server started, and opens the Server log at the day and level of the last one.