Managing secrets and certificates across environments in Boomi

An integration that syncs orders from the e-shop to the ERP needs at least two sets of credentials: one for the test ERP and one for production. Add an SFTP server for the warehouse, a client certificate for the bank, and an OAuth client for the CRM, and you have a dozen secrets per environment. This article explains how to keep them out of your process logic, and how to set that up in Boomi with environment extensions and Certificate components.

The naive approach and why it breaks

The quickest way to move a process from test to production is to open the connection, replace the test password with the production one, and deploy. It causes predictable problems:

• The next deployment overwrites production. Someone changes the process in test, redeploys, and production is now pointing at the test ERP, or using test credentials against production.
• Builders see production secrets. Anyone who can open the connection component can read or reuse them.
• Rotation becomes a project. Changing one password means editing, testing and redeploying every process that uses it.
• Certificates are forgotten. A client certificate imported two years ago expires one Saturday night, and nobody knew it existed.

The pattern: build once, configure per environment

The pattern is the same in any integration platform:

1. The process and its components are identical in every environment.
2. Everything that differs (URLs, usernames, passwords, client secrets, certificates) is configuration attached to the environment, not to the process.
3. Only a small group of administrators can set production values, and builders never need to see them.
4. Every secret and certificate has an owner and an expiry date in an inventory.

Same package ──► Test environment       (test ERP URL, svc-eshop-test, test cert)
             └─► Production environment (prod ERP URL, svc-eshop-orders, prod cert)

Step 1: Use one connection component per system

Create one connection per target system and reuse it in every process: ERP connection, Warehouse SFTP, CRM HTTP Client. Do not create “ERP test” and “ERP prod” as separate components; that leads straight back to editing processes per environment.

In the component itself, enter test values (or placeholders). They are what developers use when running in Test Mode against the development runtime.

Step 2: Mark connection fields as extensible

In Boomi, values are overridden per environment through environment extensions. You first declare which fields are extensible:

1. Open the process and go to its Extensions dialog (from the process properties area of the canvas).
2. On the Connection Settings tab, select each connection and tick the fields that differ per environment: URL, user, password, client ID and secret, and so on.
3. Do the same for anything else that varies, such as Process Properties used for folder names or company codes.
4. Save, and include the change in your next packaged deployment.

Extensions are defined per process, but the values are stored per environment and shared by every process deployed there that uses the same connection. Set a value once per environment, not once per process.

Step 3: Set the values per environment

1. Go to Runtime Management (Atom Management in older releases), select the environment, and open Environment Extensions.
2. Choose the process (or the connection) and enter the environment’s values. Password and secret fields are masked and stored encrypted.
3. Repeat for test and production. Exact screen labels can change between releases, but the flow is: environment → extensions → connection → field.

Use Boomi’s role-based access so that only administrators can edit production extensions, while builders work freely in development and test environments. With this in place, a deployment no longer carries credentials: it only carries logic.

Step 4: Manage certificates as components

Certificates in Boomi are stored as Certificate components: X.509 certificates for TLS and signing, and PGP certificates for file encryption. Typical uses:

• a client certificate (with private key, usually a .pfx or .p12 file) for mutual TLS to a bank or tax platform,
• a trusted certificate for a server whose certificate is signed by a private CA,
• PGP keys to encrypt files for a partner or decrypt files you receive.

To import one, create a new Certificate component, upload the file, and enter the key password if it has one. The component shows the subject, issuer and expiry date. Then reference it from the connection, for example in the HTTP Client connection’s SSL options for a client certificate.

When test and production use different certificates (they should), make the certificate reference an extensible field so each environment points to its own certificate. Whether a particular connector’s certificate field can be extended depends on the connector; check the Extensions dialog for the connection.

Step 5: Rotate without redeploying

With extensions in place, rotation is a configuration change:

1. Create the new credential in the target system (a new password, a new client secret, a new certificate) while the old one still works. Many systems allow two valid secrets at once for exactly this reason.
2. Update the environment extension (or import the new certificate and point the extension to it).
3. Run a quick check: trigger the process or a dedicated health-check process and confirm it succeeds.
4. Revoke the old credential.

No process is edited and nothing is redeployed. For certificates that change the process’s components, you may still need a new packaged deployment; plan that like any other release (see Packaging and deploying Boomi processes).

Step 6: Track expiry

Boomi lists the certificates in your account with their expiry dates and can warn you about certificates nearing expiry; the exact notification options vary by release, so check what your account offers. Do not rely on that alone. Keep a simple inventory:

Item	Environment	Used by	Expires	Owner
Bank mTLS client certificate	Production	Payments export	2027-03-14	Finance IT
CRM OAuth client secret	Production	CRM customer sync	2027-06-30	Integration team
Warehouse SFTP key	Production	Picking lists, stock files	No expiry, rotate yearly	Integration team

Set reminders 30 to 60 days before each date, and alert on certificate expiry from your monitoring, as described in Monitoring Boomi integrations.

Before you go live

• No production secret in any component. Search your connections: only test values or placeholders should be there.
• Extensions set in every environment before the first deployment there. A missing extension usually means the process quietly uses the component’s default value.
• Restricted access to production extensions and certificates.
• Expiry dates recorded, with an owner per item.
• A rotation rehearsal in test, so the first real rotation is not the first attempt.

Summary

Build the process once and let the environment carry the secrets: connection fields and certificate references as environment extensions, certificates as components with known expiry dates, and rotation as a configuration change. For the principles behind this, see our guide Securing integrations: a practical guide.