Administration

In 1.0.34, Settings replaces System with Access & security, Platform, Monitoring and Maintenance. Secondary navigation and focused tabs keep related settings together; existing page links and permissions remain available.

Sign-in and RBAC

• ▸Settings → Access & security → Identity providers — LDAP/LDAPS and OIDC SSO providers (generic + a Microsoft Entra ID preset), in separate tabs. Saved-setting LDAP diagnostics check connection, service bind and search, not a user password. New Active Directory configurations default to sAMAccountName; existing filters are retained.
• ▸Settings → Access & security → Users — local accounts, MFA readiness and Duo mappings, plus LDAP/SSO accounts recorded after successful authentication. Administrators can assign directory roles and disable access. Disabling invalidates sessions; re-enabling requires a fresh sign-in. Removing a user remotely is not synchronized: disable the account here too.
• ▸Settings → Access & security → Roles & permissions — map LDAP/SSO groups or usernames to viewer / operator / admin, optionally scoped to a single collection (a team sees only its own certificates), plus the default role. Enforced server-side, on the API.

Local account MFA (1.0.26)

In Account security, local users can enroll TOTP with Google Authenticator or another compatible app. Confirm the QR or manual setup with a six-digit code, then securely save the ten single-use recovery codes shown once. Test a fresh login before requiring MFA for others.

Under Settings → Access & security → MFA policy, administrators can allow optional enrollment or require MFA for local administrators or all local users. New installations and upgrades without a prior policy start optional; configured policies are retained on subsequent upgrades. SSO follows the identity provider's policy; direct LDAP is outside the local MFA policy.

• ▸Cisco Duo: configure a Duo Web SDK application for Universal Prompt with the appliance callback https://<appliance-host>/api/v1/auth/mfa/duo/callback. Enroll TOTP for the setup administrator first, save the encrypted connection settings, then map affected accounts under Settings → Access & security → Users.
• ▸Activation: all affected users need mappings. Applying the policy requires the administrator's current factor and a successful Duo authentication. Saving connection settings or a mapping alone does not prove that a user can authenticate with Duo.
• ▸Recovery: an explicitly configured Duo exception is available only for the host administrator with enrolled TOTP. That account still requires TOTP or a recovery code. Other mandatory-Duo users have no automatic fallback during a Duo outage.

AI and integration access

In the planned 1.0.38 release, configure the optional AI Assistant under Settings → Platform. Review external data processing and keep reviewed actions disabled until the read-only setup is verified. Configure separate MCP credentials and bridge access under Settings → Access & security.

Workflows and notifications

Since 1.0.36, issuance/renewal/revocation events persist separate email and Teams delivery records. History distinguishes queued, sending, provider-accepted, failed and unknown outcomes. Confirmed failures retry after 1/4/16/64 minutes, up to five attempts; accepted deliveries are not replayed. Manual retry repeats only delivery. Unknown outcomes require receiver inspection and explicit acknowledgement, because repeating may duplicate a message. Digest/test messages and Owner workflows remain separate. See 1.0.36 release notes.

Automation → Workflows binds a trigger to an ordered list of steps, each with an optional condition:

• ▸Triggers — enrollment (a certificate was issued) and expiration (a certificate entered the 30-day window, fired once per certificate).
• ▸Steps — approval (pauses until a person decides), notify (webhook or e-mail; can address {owner_email} or any {meta.*} field), and set_metadata.
• ▸Instances — every run with its step-by-step trail. Anything waiting on a decision also shows up in the unified Approvals inbox, together with pending enrollment requests.

Automation → Notifications manages recipients, the daily expiry digest and separate email/Teams lifecycle rules. Channel credentials belong under Settings → Platform → Email / SMTP and Microsoft Teams. Workflow webhooks remain separate from these notification channels.

The expiry digest includes expired and expiring certificates, excluding revoked and superseded records. Each channel has its own 24-hour acceptance clock. Explicit failures retry after 15 minutes; uncertain outcomes stop automatic retries and require checking the inbox, message trace or Workflow history before a manual retry. An empty selection advances the schedule without sending. Send expiry digest now can repeat today's digest and requires confirmation.

Issuance, renewal and revocation events use durable delivery history and retries for confirmed failures from version 1.0.36. SMTP acceptance and a successful Workflow HTTP response do not prove actual receipt. Reports, credential alerts and Owner workflow mail continue to use SMTP; enabling Teams does not reroute them.

In Notification links, optionally save the HTTPS application origin reachable by recipients, with no path, query or fragment. Leaving it blank sends messages without application links. Localhost points to the recipient's own machine. Links retain normal sign-in, MFA and permissions; they do not publish a private appliance.

Certificate Owner selection includes local and LDAP/SSO users. Directory email is read-only and refreshed after successful sign-in. Inactive owners show a warning; workflow delivery rechecks the current owner, including after an approval wait. Disabled accounts or login sources do not resolve {owner_email}; the configured global event recipients are used as fallback, and the step fails if none exist. Assigning an Owner alone does not subscribe that user to lifecycle messages: use a workflow email step with {owner_email}. This route remains SMTP-only.

Settings and notification delivery

Settings → Platform separates Email / SMTP, Microsoft Teams, discovery scanning policy and metadata. Save each section independently. Updating notification rules preserves SMTP settings and its encrypted password; concurrent changes to these separate sections are retained. Leave the saved password unchanged unless replacing or explicitly clearing it.

Save pending delivery changes before sending an SMTP test; testing is disabled while that section has unsaved edits. A saved configuration alone does not confirm mail delivery.

Microsoft 365 SMTP OAuth2

In 1.0.35, select Microsoft 365 OAuth2 to use an application credential instead of the sending mailbox password. This uses a separate Entra application with Exchange Online SMTP.SendAsApp permission and approved access to the sending mailbox. It is separate from interactive SSO and Microsoft Graph Mail.Send. The sending mailbox and From address must match. Follow the in-app M365 setup guide with your Exchange administrator, save the settings, send a test and confirm actual receipt. Plan client-secret expiry and rotation.

Microsoft Teams Workflows

Use the supported Send webhook alerts to a channel Workflow, configured for an Anyone trigger with its secret signed URL. Variants requiring a user/organization OAuth token and legacy Office 365 connector URLs are not supported. Approved HTTPS endpoints are limited to *.logic.azure.com and *.api.powerplatform.com on port 443; certificate verification is mandatory and redirects are rejected.

Save the URL under Settings → Platform → Microsoft Teams, then enable the desired rules under Automation → Notifications. Treat the URL as a credential; it is write-only and encrypted in the vault. Send a test, check the actual card and Workflow run, and maintain an appropriate Workflow owner/co-owner. Saving credentials does not automatically enable rules.

ens0key 1.0.34 · Ogledni podaci

Reports

Built-in reports (expiring within a window, full inventory, key strength, per issuer, expired/revoked) preview on screen, export as CSV or HTML, and can be e-mailed immediately or on a schedule.

Backup and restore

Settings → Maintenance → Backup & restore: separate tabs for repositories, schedule/history and restore. Define named repositories (local disk, SFTP, SCP, TFTP), run backups manually or on a schedule, optionally AES-256-GCM-encrypted. Restore replaces the database transactionally — all or nothing, from inside the app.

Audit log and SIEM

Settings → Monitoring → Logs replaces Activity. Administrators can filter platform audit events by source/category and inspect authentication attribution and event details. Selected changes show observed before/after state around the request, rather than a transactional history. Secrets and raw identity-provider responses are excluded.

ens0key 1.0.34 · Ogledni podaci

Settings → Monitoring → SIEM forwarding selects sources and categories for syslog over UDP, TCP or verified TLS, in RFC 5424, CEF or JSON format. Save changes before running a synthetic test. Send status does not prove receiver acceptance; verify receipt and field parsing in your SIEM. Local audit records remain available independently of export filters.

API error handling

Unknown API routes return a JSON 404 response in 1.0.29 instead of the web application HTML. Integrations should check the HTTP status and handle the error response, rather than treating a page response as a successful API call.

License

Settings → Maintenance → License shows the state: a fresh install runs a trial of 30 days or 10 issued certificates, whichever comes first (the trial clock is rollback-proof). Activation is a signed .lic file, verified fully offline. When a license lapses, read-only inventory and monitoring keep working; issuance, renewal and deployment pause until renewal.

Activation and removal refresh the global licensing banner immediately. Upgrades retain the existing license, node identity and trial anchor; they do not reset trial usage.