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

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.

Network scan endpoints (discovery, SSL checker) are protected against SSRF attacks:

• 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
• Cloud metadata endpoints (169.254.169.254) always blocked

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