This recipe demonstrates the same staged OV flow as the raw API recipe, but through certbro. The important difference is that certbro keeps the private key, CSR, and pending order state locally, prints the Console completion_url, and exits successfully instead of waiting forever for an order that still needs business data.

If certbro is not installed and configured yet, start with the general TLS automation with regfish certbro recipe first. This recipe assumes that certbro already works with your regfish API key and state file.

Prerequisites

• Linux with certbro already installed
• a configured state file, for example /etc/certbro/state.json
• a regfish API key with access to TLS and DNS
• a DNS zone managed through regfish DNS
• a browser-based user flow that can open the regfish Console
• optionally, a custom output directory if you want to override the default path /etc/certbro/example.com

These examples intentionally use certbro's default state path under /etc/certbro/state.json. For the example common name, certbro also derives the default output path as /etc/certbro/example.com. Add --state-file or --output-dir only if your installation uses different locations.

For OV or EV-style ordering, --org-id expects the public TLS organization id from the regfish TLS API, for example hdl_7K9QW3M2ZT8HJ. Do not pass an old numeric CA-side organization id.

Step 1: Start the OV order through certbro

To demonstrate the Console-completion path intentionally, start the OV order without --org-id. That lets certbro create the local key and CSR material, submit the technical order, and stop as soon as the TLS API reports that business completion is still required.

sudo certbro issue \
  --name example-com \
  --common-name example.com \
  --dns-name www.example.com \
  --product SecureSite

certbro validates the product against the live regfish product catalog first. For SecureSite, the TLS API can return a staged OV order with action_required=true.

Step 2: Read the staged output and keep the pending state

If the order requires Console completion, certbro issue exits successfully and prints fields such as:

• certificate_id
• pending_reason
• pending_message
• completion_url

At the same time, certbro keeps the temporary order state locally under the certificate directory, typically below:

• /etc/certbro/example.com/pending/

That is why you should not create a replacement order manually. certbro already knows how to resume the same pending order later.

Step 3: Follow the Console completion URL

Open the completion_url printed by certbro. For a staged OV order, it points into the regfish Console on the same certificate ID.

The user then finishes the business step there:

• choose an existing usable organization, or
• create a new DigiCert organization, or
• complete the remaining order step in the Console

This still belongs to the same order that certbro has already stored locally.

If the user is not logged in yet, the Console login flow should return them to the completion page afterwards.

Step 4: Resume the same order with certbro renew

After the Console step has been completed, do not run issue again. Resume the same pending order with:

sudo certbro renew --name example-com

At this point, certbro renew resumes the stored pending order, provisions DNS DCV automatically as soon as validation records become available, waits for issuance, downloads the certificate, and deploys the result into the same output directory.

If the order is still pending after a timeout, run the same renew command again. certbro continues monitoring the existing request instead of creating a duplicate order.

Step 5: Verify the final deployment

After successful completion, the stable deployment files are available under live/ and versioned snapshots under archive/.

Typical files are:

• /etc/certbro/example.com/live/fullchain.pem
• /etc/certbro/example.com/live/cert.pem
• /etc/certbro/example.com/live/chain.pem
• /etc/certbro/example.com/live/privkey.pem
• /etc/certbro/example.com/live/request.csr.pem
• /etc/certbro/example.com/live/metadata.json

You can verify the deployed certificate quickly with:

openssl x509 -in /etc/certbro/example.com/live/cert.pem -noout -subject -issuer -dates

Optional variant: pre-link a known public organization id

If you already know a usable public TLS organization id from GET /tls/organization, you can pass it up front:

sudo certbro issue \
  --name example-com \
  --common-name example.com \
  --dns-name www.example.com \
  --product SecureSite \
  --org-id hdl_7K9QW3M2ZT8HJ

If that organization is already usable for ordering, the TLS API may continue directly without returning a staged completion_url.

Practical notes for production workflows

• for a recipe that explicitly demonstrates Console completion, omit --org-id on purpose so the staged OV path becomes visible
• keep the local pending/ state intact until certbro renew has finalized the order
• after Console completion, always resume with certbro renew --name ..., not with a second issue
• use the completion_url printed by certbro, not a hardcoded Console path
• if you already know a usable organization, --org-id is the clean shortcut to avoid the staged business step
• treat --org-id as a public hdl_... id, not as an integer

Result

This workflow starts the OV order through certbro, hands the missing organization step off to the regfish Console, and then lets certbro finish the same order afterwards. That gives you the staged OV/business flow without dropping back to raw API calls or manual DCV scripting.