Log inSign upBook a demo
Tines Stories
  1. Docs
  2. Self-Hosted
  3. Upgrading Tines
  1. Docs
  2. Self-Hosted
  3. Upgrading Tines

Upgrade a FIPS deployment to OpenSSL 4

Last updated

This procedure applies to the first Tines FIPS release that uses OpenSSL 4, available as of version 44.1.3. Standard, non-FIPS deployments can follow the normal upgrade process and do not require the no-overlap cutover. The NTLM and outbound TLS compatibility checks below apply to both deployment types.

Do not perform a rolling upgrade: every process using the previous FIPS application image must stop before any process using the new image starts. The application and command-runner images must also come from the same Tines release.

What changes

The upgrade changes the cryptographic salts used by FIPS deployments for signed session cookies, Active Storage signed IDs, and MCP OAuth state. It also updates the application and command-runner runtimes to OpenSSL 4.

After the upgrade:

  • All users must sign in again.

  • Any MCP OAuth authorization that started before the upgrade must restart.

  • Existing API tokens remain valid.

  • Stored files, attachments, and file contents remain unchanged.

  • Signed Cases file GUIDs issued before the upgrade no longer validate.

  • Existing /tfile/cases/{action_guid} links remain valid.

  • HTTP Request actions configured to use NTLM fail until they use a supported authentication method.

  • Connections to destinations that only support SHA-1-based CBC cipher suites fail.

  • Built-in FIPS Run Script environments use the bundled cryptography 50.0.2 wheel.

Before the maintenance window

  1. Review the normal Infrastructure maintenance guidance and take a current database backup.

  2. Confirm that the application, Sidekiq, and command-runner images you plan to deploy have the same Tines release tag.

  3. Test the release in a non-production FIPS environment.

  4. Find HTTP Request actions that use NTLM and migrate them to a supported authentication method.

  5. Test outbound HTTPS and IMAP destinations. Update any destination that only supports SHA-1-based CBC cipher suites to support modern TLS ciphers.

  6. Review direct and transitive Python dependency pins used by Run Script actions. Update constraints that require a version of cryptography other than 50.0.2.

  7. Review external integrations that retain signed Cases file GUIDs:

    • If an integration retains case_id and file_id, it can request current file metadata or download the file after the upgrade.

    • If an integration retains only the signed guid, update it to retain case_id and file_id, and backfill those values before the upgrade.

  8. Notify users of the maintenance window and that they must sign in again afterward.

Perform the upgrade

Follow directions based on the platform you are upgrading.

Verify the upgrade

Complete these checks before ending the maintenance window:

  • Confirm that no application, Sidekiq, or command-runner process uses the previous release.

  • Confirm that all application, Sidekiq, and command-runner processes use the same release.

  • Sign in with a test user and confirm that the application loads normally.

  • Run a representative Run Script action, including one that imports cryptography if your stories use it.

  • Test representative outbound HTTPS and IMAP actions.

  • Restart and complete a representative MCP OAuth authorization.

  • Test any integration that accesses Cases files.

For integrations that retain case_id and file_id, use either of these stable endpoints:

  • GET /api/v2/cases/{case_id}/files/{file_id}/info returns current metadata and a new signed guid.

  • GET /api/v2/cases/{case_id}/files/{file_id}/download downloads the file without using a signed GUID.

Both endpoints require normal API authentication and access to the case.

Was this helpful?