xxctrustOpen console ↗
DEVELOPER RESOURCES

Trust, on your terms.

Bring certificates, OpenPGP keys, email signatures, and Debian releases into your infrastructure with scoped REST APIs and ACME.

REST API

Create a scoped bearer token in API & automation. All endpoints require HTTPS. Responses use JSON; certificate and key exports download their selected format. Signing responses contain base64 artifacts. Published-key lookup is available without authentication.

curl https://ca.xxc.dk/api/v1/certificates \
  -H "Authorization: Bearer $CA_TOKEN"

Issue a certificate

POST /api/v1/certificates
{
  "name": "service.example.com",
  "sans": ["service.example.com"],
  "authority_id": "YOUR_AUTHORITY_ID",
  "template_id": "YOUR_TEMPLATE_ID",
  "days": 30
}

Provide a PEM-encoded csr to sign your own key instead. Template policy limits validity, key generation, usage, and allowed domains.

OpenPGP, email & Debian signing

Manage keys in OpenPGP keys, prepare messages and packages in Signing tools, and discover published identities through the public key exchange.

POST /openpgp/keys · /openpgp/importGenerate keys or import one public key
POST /openpgp/keys/{id}/sign · /verifyDetached or clear OpenPGP signatures
POST /openpgp/keys/{id}/encrypt · /decryptOpenPGP encryption and decryption
POST /email/signSigned S/MIME or PGP/MIME .eml
POST /certificates/{id}/sign · /verifyS/MIME multipart or detached CMS
POST /debian/signInRelease, Release.gpg, metadata or detached package signatures
GET /exchange/keysAnonymous published-key search

Use an emailProtection template and email SANs for S/MIME issuance. Signing accepts up to 8 MiB of plaintext; verification and decryption accept envelopes up to 20 MiB. JSON requests to these endpoints are limited to 28 MiB. Responses contain base64 artifacts. Email signing validates the sender identity and returns a download; it does not send mail. Public imports require authentication, and publication requires openpgp.publish.

gpg --keyserver hkps://ca.xxc.dk --recv-keys FULL_FINGERPRINT

Debian release signing produces both InRelease and Release.gpg. Binary .deb signatures are detached; repository checksums must be prepared by your packaging tools. Check the OpenAPI schemas for permissions, limits and request formats.

Core endpoints

GET /certificatesSearch, status, authority, page
POST /certificatesIssue or sign a CSR
GET /certificates/{id}/downloadPEM, DER, or chain
POST /certificates/{id}/downloadPrivate key or protected PKCS#12
POST /certificates/{id}/revokeRevoke with a reason
GET /authorities · /templatesDiscover issuance policies
GET /activityAudit, access, operator, download logs

Paths above are relative to /api/v1. See the OpenAPI specification for request schemas and administration endpoints.

Sign an email

Issue a certificate with an emailProtection template and email subject alternative names. Export a protected PKCS#12 bundle for your mail client, or sign a message through the API.

POST /api/v1/email/sign
{
  "scheme": "smime",
  "certificate_id": "YOUR_EMAIL_CERTIFICATE_ID",
  "from": "sender@example.com",
  "to": ["recipient@example.net"],
  "subject": "Signed update",
  "body": "Your message here."
}

For PGP/MIME, use scheme: openpgp and key_id. The sender must match an identity in the signing key or certificate. The response contains a signed .eml message for your own mail pipeline, with a plain-text body up to 1 MiB.

Use email.sign, plus openpgp.sign for PGP/MIME. S/MIME recipients need to trust this private CA’s root.

Sign a Debian release

Send unsigned metadata to POST /api/v1/debian/sign with a signing key, an artifact kind, and base64 file contents.

{
  "key_id": "YOUR_SIGNING_KEY_ID",
  "kind": "release",
  "data_base64": "BASE64_RELEASE_FILE"
}

release returns both InRelease and Release.gpg. Use dsc, changes, or buildinfo for clear-signed metadata; deb returns a detached binary-package signature.

Prepare checksums with your packaging tools before signing. Distribute your public key as a dedicated APT keyring and reference it with Signed-By. The token needs openpgp.sign.

Download the complete API specification →

ACME enrollment

Choose an issuer and TLS template in Administration. Generate a one-time external account binding credential from API & automation.

certbot certonly --manual \
  --preferred-challenges dns \
  --server https://ca.xxc.dk/acme/directory \
  --eab-kid "$EAB_KID" \
  --eab-hmac-key "$EAB_KEY" \
  -d service.example.com

Supports DNS-01 and HTTP-01, RS256 and ES256 account keys, account deactivation, and certificate revocation. HTTP-01 requires a public IPv4 address on port 80, without redirects. Wildcards and account key rollover are not supported.

This is a private CA. Install its root certificate in your clients’ trust stores before using issued certificates.

Webhook delivery

Subscribe to certificate and user events. Generic webhooks include an event ID and an HMAC-SHA256 signature of timestamp + "." + body. Verify using your webhook secret and reject stale timestamps.

Deliveries retry up to five times. Destination URLs must use HTTPS and resolve to public IPv4 addresses.