canonical: https://jentic.com/apis/bounca.org/bounca

# BounCA API

Jentic writes and maintains this OpenAPI specification for BounCA API, keeping it validated and agent-ready. BounCA also self-serves its own Swagger 2.0 document at `/api/swagger.json` on every instance. BounCA is a self-hosted PKI certificate authority management tool built on Django REST Framework that issues and manages Root CAs, Intermediate CAs, and end-entity certificates for servers, clients, and code signing. The API exposes login, certificate creation, revocation, renewal, CRL handling, and certificate download so platform teams can automate internal PKI from CI pipelines or AI agents. Authentication uses a bearer token issued via `/auth/login`/ or a session cookie.

## For AI agents

Issue, renew, revoke, and download X.509 certificates from a self-hosted BounCA certificate authority across 14 endpoints.

## Scope

Does not handle hardware security module key storage, secret rotation, or DNS-01 ACME challenges - use for self-hosted X.509 certificate issuance, revocation, renewal, and CRL handling only.

## Capabilities

- Issue Root CAs, Intermediate CAs, and end-entity certificates from a self-hosted PKI
- Revoke a certificate and update the corresponding certificate revocation list
- Renew an existing certificate before expiry without rotating the private key
- Download issued certificates in PEM bundles for distribution to services
- Read certificate metadata including issuer, subject, serial, and expiry
- Authenticate with a username and password to obtain a bearer token
- Generate or refresh the CRL for a certificate authority

## Use cases

### Automated internal certificate issuance from CI

Platform teams running a self-hosted BounCA wire certificate issuance into their CI pipeline so that each new internal service gets a freshly issued certificate without a ticket. The pipeline calls POST `/auth/login`/ for a token, POST /certificates/ with the CSR or subject details, and GET `/certificates/{id}/download`/ to fetch the PEM bundle. Most platform teams ship the integration in a couple of days.

Example prompt: Authenticate with username deploy and password from the vault, issue a server certificate for CN api.internal.example with a 365-day validity, and return the certificate id

### Certificate revocation and CRL refresh

Security operations revoke a certificate when a host is decommissioned or a private key is suspected compromised, and they need a fresh CRL distributed to consumers. POST `/certificates/{id}/revoke`/ revokes the certificate and POST `/certificates/{id}/crl`/ regenerates the CRL for downstream distribution. Both operations are scriptable and typically wrap into an incident response runbook.

Example prompt: Revoke certificate id 999 with reason 'keyCompromise', then regenerate the CRL for its issuing CA and confirm the new CRL serial

### Pre-expiry renewal of long-lived certificates

Platform teams renew CAs and long-lived service certificates before they expire to avoid outages. POST `/certificates/{id}/renew`/ creates a new certificate with the same subject, and GET `/certificates/{id}/info`/ confirms the new expiry. A nightly job that scans for certificates expiring in the next 30 days and renews them prevents silent failures.

Example prompt: List certificates expiring within 30 days, then call the renew endpoint for each and report the new expiry dates

### Agent-driven internal PKI via Jentic

An AI agent embedded in a platform team's chat workflow handles requests like 'issue a cert for grafana.internal valid for one year' by calling BounCA. Through Jentic the agent searches for 'issue a BounCA certificate', loads the schema, and executes the call while the bearer token stays in your Jentic One instance.

Example prompt: Search Jentic for 'issue a BounCA certificate', load the schema, and execute it for CN grafana.internal with a 365-day validity, returning the download URL

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/auth/login/` | Authenticate and receive a bearer token |
| POST | `/certificates/` | Issue a new certificate |
| GET | `/certificates/` | List certificates in the BounCA host |
| POST | `/certificates/{id}/revoke/` | Revoke an issued certificate |
| POST | `/certificates/{id}/renew/` | Renew an existing certificate |
| GET | `/certificates/{id}/download/` | Download the certificate PEM bundle |
| GET | `/certificates/{id}/info/` | Read certificate metadata |
| POST | `/certificates/{id}/crl/` | Regenerate the CRL for the issuing CA |

## Key resources

- **Authentication** — Login, logout, and current-user endpoints that issue bearer tokens or session cookies
- **Certificates** — Create, list, retrieve, update, and delete certificates of all types (Root CA, Intermediate CA, end-entity)
- **Revocation** — Revoke a certificate and trigger CRL regeneration
- **Renewal** — Renew an existing certificate before expiry
- **Download** — Fetch the PEM bundle for an issued certificate

## Why Jentic

- **Setup:** Wiring BounCA by hand means logging in at `/auth/login`/ for a bearer token, pointing at your own self-hosted host, and carrying that token through the certificate lifecycle calls. Through Jentic you install once, import the BounCA API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** BounCA puts the certificate id in the URL path (`/certificates/{id}/revoke`/, `/certificates/{id}/renew`/), so a rule can pin your agent to one certificate. You choose the operations it may call, so destructive ones like revoke are only included if you add them, and an agent that only issues or downloads certificates can be scoped to those paths.
- **Credential handling:** Your BounCA bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'issue a BounCA certificate' or 'revoke a certificate', and Jentic returns the matching BounCA operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **SSL Labs API** — TLS configuration scanner that pairs with BounCA to validate the certificates it issues are deployed correctly.
- **HashiCorp Nomad API** — Workload orchestrator commonly running services that consume BounCA-issued certificates.
- **Evervault API** — Managed encryption and key custody service rather than a self-hosted CA.

## FAQ

### Does BounCA publish an official OpenAPI specification?

Yes. BounCA is a Django REST Framework application that ships drf-yasg, so every BounCA instance self-serves a Swagger 2.0 document at `/api/swagger.json` and `/api/swagger.yaml.` BounCA's own hosted instance serves it at https://app.bounca.org/api/swagger.json, covering 23 paths. This Jentic specification is written from the endpoints documented on bounca.org and declares the bearer token and session cookie schemes that the self-served document leaves out, so use whichever matches your deployment. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the BounCA API use?

BounCA supports HTTP bearer tokens issued by POST `/auth/login`/ and Django session cookies. For programmatic and agent use, prefer the bearer token; in Jentic the token is stored in the vault and injected at execution so it never enters the agent's context.

### Can I issue a server certificate with the BounCA API?

Yes. POST /certificates/ with the certificate type set to a server cert and the required subject information; BounCA returns the new certificate id, and GET `/certificates/{id}/download`/ fetches the PEM bundle for deployment.

### How do I revoke a certificate and refresh the CRL through Jentic?

Run pip install jentic, then search Jentic for 'revoke a BounCA certificate', load the POST `/certificates/{id}/revoke`/ schema, and execute it with the certificate id and revocation reason. Follow with the /crl/ endpoint to regenerate the CRL.

### What are the rate limits for the BounCA API?

BounCA is self-hosted, so there are no vendor-imposed rate limits in the spec; throughput is bounded by the host running BounCA. Use the bulk listing endpoint with pagination instead of per-id loops, and serialize CRL regeneration to avoid concurrent CA updates.

### Can I renew an existing certificate before it expires?

Yes. POST `/certificates/{id}/renew`/ creates a new certificate that reuses the same subject and CA as the original. Combine it with GET /certificates/ filtered by expiry to build a recurring renewal job.

### Can I limit what my agent is allowed to do with the BounCA API?

Yes. Because you run Jentic One yourself, your own rules decide which BounCA operations and credentials the agent may use, so you can grant an agent only issuing and download paths like POST /certificates/ and GET `/certificates/{id}/download`/ while withholding destructive ones such as POST `/certificates/{id}/revoke/.` Since BounCA puts the certificate id in the URL path, a rule can also pin the agent to a single certificate for renewal or revocation. The bearer token is stored by your instance and injected at execution, so the operator, not the agent, controls what it can call.
