Security and TLS

Password management, TLS certificates, and audit logging

The management platform is penetration tested before every release. If your organization requires security evidence for procurement or compliance reviews, test reports are available on request.

Authentication

Password

The board uses a single shared password for dashboard and API access. On first boot, the default password is admin and must be changed before any features are accessible.

Password requirements:

  • Minimum 8 characters
  • Changing the password invalidates all active sessions (all users must log in again)

Sessions

  • Login returns a Bearer token valid for 24 hours
  • Tokens are invalidated on password change or logout
  • Login is rate-limited to 10 attempts per minute per IP address

Changing Your Password

  1. Click Settings or the gear icon in the dashboard
  2. Enter your current password
  3. Enter and confirm your new password
  4. Click Change Password

All existing sessions are invalidated. You will be redirected to the login page.


TLS Certificates

The dashboard is served over HTTPS. Three certificate modes are available:

Self-Signed (Default)

A self-signed certificate is generated automatically on first boot. The dashboard works immediately. Browsers will show a certificate warning, which is expected and can be safely accepted for local network use.

Custom Certificate Upload

Upload your own certificate for trusted HTTPS without browser warnings:

  1. Obtain a certificate from your Certificate Authority (or internal CA)
  2. Go to the TLS settings in the dashboard
  3. Upload the certificate file (.crt or .pem) and private key file (.key)
  4. The certificate is applied immediately with no service restart

The hot-swap is atomic. Active connections continue on the old certificate; new connections use the new one.

ACME (Let’s Encrypt) - HTTP-01

For boards with a public DNS name and inbound internet access:

  1. Assign a DNS name to the board’s IP address
  2. Go to the TLS settings and select ACME mode
  3. The platform requests a certificate from Let’s Encrypt
  4. Certificates auto-renew before expiry

Requirements:

  • The board must have a public DNS name
  • Port 80 must be accessible from the internet (HTTP-01 challenge)

DNS-01 Challenge for Air-Gapped Deployments

For boards on private networks, air-gapped environments, or deployments where the board cannot be exposed to the internet, use the DNS-01 challenge method. This is the recommended approach for government, defense, and enterprise environments.

With DNS-01, the board never needs inbound internet access. A separate machine with internet access handles the certificate request:

  1. Run certbot on any machine with internet access:
    sudo certbot certonly --manual --preferred-challenges=dns \
      -d board.yourdomain.com
    
  2. Certbot displays a TXT record value to add to your DNS
  3. Add the _acme-challenge.board.yourdomain.com TXT record at your DNS provider
  4. Verify propagation: dig +short TXT _acme-challenge.board.yourdomain.com
  5. Press Enter in certbot to complete validation
  6. Push the certificate to the board:
    curl -k -X POST \
      -H "Authorization: Bearer <token>" \
      -F "cert=@/etc/letsencrypt/live/board.yourdomain.com/fullchain.pem" \
      -F "key=@/etc/letsencrypt/live/board.yourdomain.com/privkey.pem" \
      https://<board-ip>/api/v1/system/tls/upload
    

The certificate is hot-swapped atomically. No service restart required.

For fleet deployments, this process can be fully automated if your DNS provider offers API access for programmatic TXT record creation. Supported providers include Cloudflare, DigitalOcean, AWS Route 53, and Google Cloud DNS. Not all DNS providers support API automation (for example, name.com does not), but the manual workflow above still works with any provider. Wildcard certificates (*.boards.example.com) are also supported with DNS-01, allowing a single cert to cover an entire fleet.

Let’s Encrypt certificates expire after 90 days. Set up a cron job on the renewal machine to automate the process.

Viewing Certificate Info

The dashboard shows the current certificate details including:

  • Subject (CN and SANs)
  • Issuer
  • Expiry date
  • Current mode (self-signed, upload, or ACME)

Audit Logging

Every action that changes board state is recorded in the audit log:

FieldDescription
TimestampWhen the action occurred
ActionWhat was done (e.g., port_disable, password_change, fleet_pair, reboot)
ActorIP address of the user who performed the action
TargetWhat was affected (e.g., pse0/port3, fleet/CRU-000012)
DetailAdditional context

Viewing the Audit Log

The most recent entries appear in the Recent Activity section at the bottom of the dashboard. Click to expand and see more entries.

The full audit log is available via the API with pagination:

curl -k -H "Authorization: Bearer <token>" \
  "https://<board-ip>/api/v1/system/audit?limit=50&offset=0"

Log Retention

Audit logs are stored in the board’s SQLite database and included in backup exports. Logs persist across reboots and service restarts.


Network Security

Local-Only by Default

The management platform listens on the board’s network interfaces. It is accessible to any device on the same network. There is no cloud component, no external account, and no outbound data transmission (except ACME certificate requests if enabled).

HSTS

HTTP Strict Transport Security headers are enabled by default with a 1-year max-age. This tells browsers to always use HTTPS when connecting to the board.

No External Dependencies

The platform requires no internet connectivity for normal operation. All features work on air-gapped networks. The only feature that requires internet access is ACME (Let’s Encrypt) certificate provisioning.

Fleet Security

Fleet communication between paired boards uses Ed25519 digital signatures. Each request includes a signed timestamp with a 5-minute replay window. Board identity is verified against stored public keys from the pairing process.

Last modified April 9, 2026