Ultimate Certificate Manager implements comprehensive security features to protect your PKI infrastructure.

All private keys (CA and certificate) are encrypted at rest using Fernet encryption (AES-256-CBC with HMAC-SHA256).

Private key encryption is managed from Settings > Security in the web UI. The master key is stored at /etc/ucm/master.key.

Alternatively, via API (using session cookies):

# Encrypt existing keys (dry run first)
curl -k -b cookies.txt -X POST https://localhost:8443/api/v2/system/security/encrypt-all-keys \
  -H "Content-Type: application/json" \
  -d '{"dry_run": true}'

# Then actually encrypt
curl -k -b cookies.txt -X POST https://localhost:8443/api/v2/system/security/encrypt-all-keys \
  -H "Content-Type: application/json" \
  -d '{"dry_run": false}'

• Keys stored encrypted in database with ENC: prefix
• Decrypted only when needed (export, signing)
• Original keys never logged

When private-key encryption is enabled, UCM does not keep plaintext key files in the data/private/ directory. Existing mirrors are removed when encryption is enabled and on every start; public certificate files remain untouched. If a local service needs certificate and key files, use a deploy hook, including a same-host SFTP target for services running on the UCM host. Private-key export through the API remains permission-gated by read:private_keys.

When KEY_ENCRYPTION_KEY enables encryption through the environment, the same startup purge applies. Move any consumer that reads data/private/ directly to a deploy hook or the API before restarting with this setting.

Cross-Site Request Forgery protection for all state-changing requests.

1. Login/verify response includes csrf_token
2. Client stores token in sessionStorage
3. Client sends X-CSRF-Token header on POST/PUT/DELETE/PATCH
4. Server validates token signature and expiry

timestamp:nonce:hmac_signature

• Valid for 24 hours
• Signed with SECRET_KEY

• /api/v2/auth/login (needs to get token)
• /acme/, /scep/, /ocsp, /cdp/ (protocol endpoints)
• /api/health (monitoring)

Strong password enforcement for all user accounts.

• Common passwords (password123, admin, etc.)
• 4+ sequential characters (abcd, 1234)
• 4+ repeated characters (aaaa, 1111)

# Get policy
GET /api/v2/users/password-policy

# Check strength (returns score 0-100)
POST /api/v2/users/password-strength
{"password": "MyP@ssw0rd!"}

Protection against brute force and DoS attacks.

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 115
X-RateLimit-Reset: 1706789123

{
  "success": false,
  "error": "Rate limit exceeded",
  "retry_after": 45
}

# Get config and stats
GET /api/v2/system/security/rate-limit

# Add IP whitelist
PUT /api/v2/system/security/rate-limit
{"whitelist_add": ["192.168.1.100"]}

# Reset counters for IP
POST /api/v2/system/security/rate-limit/reset
{"ip": "192.168.1.50"}

Comprehensive logging of all security-relevant actions.

• Authentication (login, logout, failures)
• User management (create, update, delete)
• Certificate operations (issue, revoke, export)
• CA operations (create, delete, sign)
• Settings changes
• Security events (rate limited, permission denied)

# Get retention settings
GET /api/v2/system/audit/retention

# Update retention (days)
PUT /api/v2/system/audit/retention
{"retention_days": 365, "auto_cleanup": true}

# Manual cleanup
POST /api/v2/system/audit/cleanup
{"retention_days": 90}

Default: 90 days, auto-cleanup daily at midnight.

Proactive email notifications before certificates expire.

• 30 days before expiry
• 14 days before expiry
• 7 days before expiry
• 1 day before expiry

# Get settings
GET /api/v2/system/alerts/expiry

# Update settings
PUT /api/v2/system/alerts/expiry
{
  "enabled": true,
  "alert_days": [30, 14, 7, 1],
  "recipients": ["admin@example.com"]
}

# List expiring certificates
GET /api/v2/system/alerts/expiring-certs?days=30

# Manual check
POST /api/v2/system/alerts/expiry/check

Requires SMTP configuration in Settings > Email.

Two guards, because the two jobs have different answers.

Network scan endpoints (discovery, SSL checker) use validate_url_not_private:

• Private/loopback IP ranges blocked by default (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• DNS rebinding protection: resolved IPs are validated against the blocklist
• Configurable allowlist for internal network scanning use cases

User-supplied outbound URLs (webhooks, SSO, ACME, imports) use validate_url_not_cloud_metadata, which blocks cloud metadata and loopback while deliberately allowing the LAN. UCM is deployed on premises: an RFC1918 webhook or an internal SSO endpoint is the primary use case, not an attack.

• Cloud metadata endpoints always blocked: the link-local address every major provider answers on, plus the ones that sit elsewhere (Oracle Cloud, Scaleway, and Google's and Alibaba's named forms)
• An IPv4 address written as IPv6 is read back and judged the same way, in each of the six forms that reach the same host: mapped, the deprecated compatible form, 6to4, Teredo, ISATAP and NAT64. For NAT64's local-use prefix, where the specification allows several layouts and the address does not say which is in use, every layout is read and judged against the metadata endpoints

WebAuthn authentication includes rate limiting:

• Failed attempts tracked per user
• Account lockout after repeated failures
• Separate rate limit from password login

All SSO authentication events are logged:

• Login attempts (success/failure) with provider type
• LDAP bind errors (generic messages to prevent enumeration)
• OAuth2/SAML token validation failures
• Session creation from SSO providers

A consolidated audit landed in v2.142. All changes are operator-transparent except where noted in the right column.

The hardening pass also exposed reusable helpers in backend/utils/:

SSRF policy reminder. UCM is on-prem. RFC1918, loopback, .lan/.local/.corp are the primary use case, not an attack vector. Use validate_url_not_cloud_metadata (blocks cloud-metadata + loopback only) for any user-supplied outbound URL, never validate_url_not_private, which would break LAN webhooks, internal SSO, and local ACME validation.

Second consolidated audit. Operator-transparent unless noted.

Operators can now take any CA offline to prevent unauthorized signing. Two modes are exposed:

Threat model:

• Stolen DB only: password_protected keys remain encrypted under both the master key and the offline password. file_exported keys are absent entirely.
• Stolen DB + master key: password_protected keys still require the offline password. file_exported keys are absent.
• Stolen offline file: useless without the password (PKCS#8 password-encrypted; standard cryptography library hardening).
• Forgotten password: no recovery. The CA is unrecoverable. This is by design.

Sign/issue/CRL paths gate on ca.offline (see services/ca/ca_signing.py:31, csrs.py:689, services/cert/mixins/csr.py, crl.py:97). The update_ca endpoint can no longer flip the offline flag, only the dedicated take_offline / restore endpoints do, both of which require the password.

Audit actions: ca.offline.password_protected, ca.offline.file_exported, ca.restore.password_protected, ca.restore.file_exported. The legacy free-text "offline reason" field is no longer collected, the mode IS the audit record.

Password policy for the offline password is the same as the user password policy (12+ chars, mixed classes, no 4+ sequential).

# 1. Change default admin password immediately
# 2. Generate and set encryption key
# 3. Configure HTTPS with proper certificate
# 4. Set strong SECRET_KEY in /etc/ucm/ucm.env

# /etc/ucm/ucm.env
SECRET_KEY=<random-64-char-string>
KEY_ENCRYPTION_KEY=<fernet-key>
FLASK_ENV=production

• Run behind reverse proxy (nginx, Caddy)
• Enable firewall, restrict access to port 8443
• Use proper TLS certificate (not self-signed in production)

• Encrypted backups include encryption key
• Store backups securely off-server
• Test restore procedures regularly

Access security metrics at Settings > Audit Logs:

• Failed login attempts
• Rate limited requests
• Permission denied events
• Certificate operations

If you discover a security vulnerability, please report it responsibly:

1. Do NOT create a public GitHub issue
2. Open a GitHub Security Advisory
3. Include: description, steps to reproduce, impact assessment
4. Allow 90 days for fix before public disclosure