Operations

Follow identities and activity.

The /devices portal lists issued certificate identities, serials, DNS SANs, issuance times, expiry dates, and status. The /activity page records issuance, renewal, failures, and lifecycle changes. Inventory entries describe certificates; they are not a live endpoint-health or hardware inventory agent.

Use devica subca status to inspect the active device authority. Check application /health, proxy reachability, and the enrolment and revocation URLs from the networks where your clients run.

Renewal is client-driven.

The SCEP renewal path uses an existing device certificate to authenticate the request. The certificate must be issued by this authority, remain within validity, and be inside the configured renewal window. The renewed request must preserve the identity. Your SCEP client must initiate renewal.

Certificate lifetime defaults to 90 days through DEVICA_DEVICE_CERT_DAYS. DEVICA_RENEW_BEFORE_DAYS defaults to 30. Windows scripts and Android credential downloads do not install a general automatic renewal agent; plan credential replacement for those endpoints.

The portal highlights certificates nearing expiry. The reminder horizon defaults to 14 days through DEVICA_RENEWAL_REMINDER_DAYS, with repeat notifications every 7 days through DEVICA_RENEWAL_REMIND_EVERY_DAYS.

With DEVICA_CRL_AUTO=true (the default), the running web service performs daily maintenance, including expiry processing, CRL rebuild, and configured renewal email. The first automatic run occurs after the daily interval. The CLI maintenance command expires inventory records and rebuilds the CRL; it does not send the web service’s configured renewal digest in this checkout.

Hold, release, or revoke a certificate.

Administrators and operators can suspend a certificate with certificateHold, release that hold, or revoke it with a reason on /devices. These portal actions rebuild the CRL when an active authority is available. Permanent revocations cannot be released as holds.

CRL is served at /crl. OCSP supports POST at /ocsp and encoded GET requests. Clients use the corresponding distribution/status URLs embedded during issuance. Configure the relying RADIUS server, VPN gateway, or application to check and enforce revocation; status publication alone does not immediately disconnect an endpoint.

# Substitute the issued certificate's actual hexadecimal serial.
docker compose exec ca devica device revoke \
  --serial CERTIFICATE_SERIAL --reason keyCompromise
docker compose exec ca devica maintenance run
# Separately revoke any associated enrolment token by its ID:
docker compose exec ca devica token list
docker compose exec ca devica token revoke --id TOKEN_ID

Replace the uppercase placeholders with real serial and token IDs. Token lists show IDs and usage metadata, not the original secret. Before offboarding a device, also review access policies and client renewal behaviour in your deployment.

Portal roles and account recovery.

Each account can enrol TOTP at /security. Save recovery codes when displayed; each works once. If an administrator needs to reset a lost second factor, the CLI exposes an account recovery command. It also removes that account’s current sessions:

docker compose exec ca devica admin list
docker compose exec ca devica admin reset-totp --email admin@example.com

Run recovery only from your protected application administration environment. Keep HTTPS and DEVICA_COOKIE_SECURE=true for portal sessions.

Email and external syslog.

Administrators configure SMTP and renewal-digest recipients at /email. Test the delivery settings. Unconfigured email sends no digest; failures are recorded as activity and do not mark notifications as successfully sent.

External syslog is disabled until DEVICA_SYSLOG_HOST is set. UDP, TCP, and TLS are supported; TLS defaults to port 6514 and verifies the collector certificate. Mount any configured CA/client certificate files into the service.

DEVICA_SYSLOG_HOST: "syslog.example.com"
DEVICA_SYSLOG_PROTOCOL: "tls"
DEVICA_SYSLOG_PORT: "6514"
DEVICA_SYSLOG_TLS_CA: "/run/secrets/syslog-ca.pem"

Shipping is best-effort, not a guaranteed durable audit export. The devica-serve entrypoint configures logging; a custom ASGI launcher must arrange that explicitly. Access logging is off unless DEVICA_SYSLOG_ACCESS_LOG=true.

Back up keys, database, and secrets together.

The Docker devica-state volume holds the SQLite database, encrypted sub-ca-keys/, and secrets.env. Back up all of them together. Losing the passphrase or private keys prevents recovery of the signing authority.

# Stop the SQLite-writing application for a consistent file backup.
docker compose stop ca
docker run --rm -v devica-state:/state:ro -v "$PWD":/backup alpine \
  tar czf /backup/devica-state.tgz -C /state .
docker compose start ca

The example briefly stops the app. Check backup completion before restarting; protect the archive with restricted access and your backup encryption policy. For MariaDB, take a coordinated database backup as well as the key/secret volume backup. Local Python deployments need the equivalent protected state-directory backup.

Test restoration into an isolated instance with the original state ownership, passphrase, and database configuration. Keep the existing deployment stopped during restoration. Do not run the application’s destructive smoke-test cleanup against real state, or use docker compose down -v on a deployment you intend to preserve.

Before upgrading, obtain the agreed updated source and create a tested backup. Builds are local; pulling an unspecified public image is not an upgrade path. Database migrations run at startup, so rollback may require the pre-upgrade database and keys.

# After obtaining the agreed updated source and backing up:
./scripts/build-image.sh
docker compose up -d
docker compose exec ca devica subca status
docker compose logs ca

If using the MariaDB overlay, use the same pair of Compose files for lifecycle commands. Confirm portal access, authority status, CRL/OCSP reachability, and a designated test endpoint after the update.