Skip to main content

Key Management

Secrets are the credentials (API keys, passwords, SSH private keys, and shared secrets) that grant access to your agency's eCourtDate data and integrations. Think of them like physical keys to a secure room: anyone who has them can get in, so they must be stored carefully, never shared carelessly, and replaced immediately if lost or compromised.

Platform Key Architecture​

eCourtDate relies on AWS Key Management Service (KMS) within GovCloud for platform-level encryption keys. These keys are managed within FIPS 140-2/140-3 validated hardware security modules (HSMs) and are used for encrypting data at rest and in transit.

info

For details on HSM configuration, key hierarchy, and platform-level key rotation schedules, contact the eCourtDate security team through the Help Center.

Secret Types and Lifecycle​

Secret TypeCreated InRotation MethodNotes
API Credentials (client_id / client_secret)Console > APIsGenerate new credentials in ConsoleOld credentials are revoked on regeneration
SSH Keys (SFTP)Generated locallyUpload new public key to ConsoleMultiple keys can be active during transition
OAuth Client SecretsIdentity Provider (Azure AD, Google, Okta)Rotate per IDP documentationManaged outside eCourtDate
Webhook Shared SecretsConsole > WebhooksUpdate in Console and your application simultaneouslyMax 24 characters

API Secrets (client_id / client_secret)​

  • Store in environment variables, never in source code
  • Rotate credentials periodically via Console > APIs
  • Use separate credentials for staging and production
  • Revoke compromised credentials immediately

See API Authentication for the OAuth 2.0 Client Credentials flow.

SSH Private Keys (SFTP)​

  • Store in ~/.ssh directory only
  • Set permissions to read-only: chmod 400 {key.pem}
  • Never commit to version control repositories
  • Never share via email or chat
  • Use separate keys per environment/server

See SFTP Authentication for setup instructions and supported key formats.

OAuth Client Secrets​

  • Managed in your Identity Provider (Azure AD, Google, Okta, etc.)
  • Store application secrets in environment variables
  • Rotate secrets periodically per IDP documentation

See OAuth Security for SSO security requirements.

Webhook Shared Secrets​

  • Max 24 characters
  • Set via environment variable (e.g., WEBHOOK_SECRET)
  • Rotate by updating in both Console and your application simultaneously
  • Combine with IP allowlisting for defense in depth

See Webhook Verification for HMAC-SHA256 implementation details.

Rotation Best Practices​

  • Follow agency policy: Rotate credentials on the schedule required by your organization's security policy (CJIS typically requires rotation at defined intervals)
  • Rotate on personnel changes: When staff with access to secrets leave or change roles, rotate all credentials they had access to
  • Coordinate webhook rotations: When rotating webhook shared secrets, update the Console and your receiving application at the same time to avoid dropped events
  • Document procedures: Maintain a runbook for credential rotation so the process is repeatable and not dependent on a single person
  • Review periodically: Audit active API clients, SSH keys, and webhook configurations to identify unused credentials that should be revoked
danger

Never include secrets in support tickets, log files, error messages, or documentation. If a secret is compromised, rotate it immediately.