Automated SSL certificate renewal for Boomi

Boomi won't roll a renewed certificate out to your runtimes. CertKit will.

Boomi stores certificates as X.509 components. Self-hosted Atoms and Molecules serve one from their Shared Web Server, and the API Gateway and Developer Portal each point at one. A new component version does nothing until each runtime re-saves its settings and restarts, and each gateway and portal is upgraded to it. Every 47 days.

CertKit issues and renews the certificate centrally, then the CertKit Agent updates the component through the Boomi Platform API and pushes it to every runtime you list.

Start free trial Watch demo

Built for Boomi

Pre-built templates for runtimes, the API Gateway, and the Developer Portal ship in your CertKit account. No scripting required.

Each template updates the same certificate component in place, so its ID stays stable and every reference keeps working. For runtimes, CertKit pushes the certificate to each Shared Web Server and restarts it.

Boomi has no API for the gateway and portal bindings, so those still need one click on Upgrade to Latest after each renewal. The deployment log says exactly where.

How to update an SSL certificate in Boomi

The manual process, if you want to do it yourself:

Get the certificate as a PFX. It must cover the hostname clients use for the runtime, gateway, or portal.
Update the certificate component. In Build, open the X.509 certificate component, import the new PFX, and save.
Push it to each runtime. In Manage → Runtime Management, open each runtime's Shared Web Server settings, select the certificate again, and save.
Restart the runtimes. A runtime only serves the new certificate after a restart, which stops work running on it.
Upgrade the gateway and portal. In API Management → Gateways → Location Settings, click Upgrade to Latest on the Certificate field. Do the same under Developer Portal Settings.

Every one of these steps is manual, and Boomi won't repeat any of them when the certificate renews. With lifetimes shrinking to 47 days, that's twelve times a year, for every runtime, gateway, and portal. Miss one and partners calling your APIs get TLS errors instead of responses.

At 47 days, automation is the only sustainable way to run Boomi certificates. Here's how CertKit does it.

How it works

 Your Boomi account      CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│  ┌─────────────┐  │     │                  │    │             │
│  │Deploy Agent │◄─┼─────┤  Issue & Renew   │◄──►│             │
│  └──┬────┬─────┘  │     │   Certificates   │    │             │
│     │    │Platform│     │                ┌───┐  └─────────────┘
│     │    │API     │     └───────────┬────│DNS│
│     ▼    ▼        │                 │    └───┘
│ ┌──────────────┐  │                 │
│ │ Boomi        │  │                 │
│ │ [x] Component│  │                 │
│ │ [x] Pushed   │  │ ◄───────────────┘
│ │ [x] Restarted│  │       Verify
│ └──────────────┘  │
└───────────────────┘

CertKit issues and renews certificates centrally using delegated DNS validation. You create a one-time CNAME record, and CertKit handles every ACME challenge after that.

The deploy agent runs on a Windows server and pulls each renewal from CertKit over outbound HTTPS. It only needs to reach Boomi's Platform API, not the runtimes themselves. Boomi never runs ACME and never holds DNS credentials.

CertKit has transformed how Belden manages SSL certificate issuance, delivering a streamlined process that dramatically reduced both cost and complexity. Their solution has been a clear win for our organization.

Ryan Buckner, IT Infrastructure Analyst, Belden

What CertKit handles

Issue and renew centrally. The one-time CNAME covers every renewal challenge.
Update the component in place. The first run creates it, and every renewal after that adds a new version to the same component.
Push to every runtime you list. CertKit re-saves each Shared Web Server and restarts it, or leaves the restart to you. Boomi-hosted Clouds are skipped, since they only use Boomi's certificate.
Check the hostname first. For the gateway and portal, CertKit stops before uploading if the certificate doesn't cover the public hostname.
Verify and alert. CertKit checks that the new certificate is being served and alerts on API or restart failures.
Audit every change. Every issuance, renewal, and deployment is logged. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit.
Create a Platform API token. Under Settings → My User Settings → Platform API Tokens. The token's user needs API Access and Build, plus Runtime and Environment Management for runtime restarts.
Install the CertKit Agent. One command on a Windows host that can reach Boomi's API.
Add the Boomi deployment script. Choose the runtime, gateway, or portal template, then enter the account ID, token, component name, and runtime names or hostname.

See the full architecture →

Boomi deployment requirements and troubleshooting →

Why updating the component isn't enough

Boomi doesn't push component changes on its own. A runtime keeps serving the old certificate until its Shared Web Server settings are saved again and it restarts, and a gateway keeps it until someone upgrades the reference. The component shows the new certificate while production serves the old one until it expires.

CertKit does the push and the restarts on every renewal, and names the one click Boomi still requires.

Boomi is just one part of your integration stack

The systems Boomi connects need certificates too: systems of record like IBM i, Java servers like Oracle WebLogic, and cloud services fed from Azure Key Vault. CertKit automates all of it from one account.

See all integrations

Start automating Boomi certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing