# HALOWERK sicherwerk PKCS#12 Certificate Trust Store Builder

> HALOWERK sicherwerk PKCS#12 Certificate Trust Store Builder is a paid API for AI agents from sicher.halowerk.com, paid per call via x402, $0.002/call, status unknown (last checked 2026-10-29).

Builds a PKCS#12 trust store container from one or more PEM certificates, explicitly with no private keys and an empty password

## Facts

- Endpoint: POST https://sicher.halowerk.com/v1/oss-openssl-pkcs12-certificate-store-build?utm_source=zero.xyz
- Price: $0.002/call
- Payment: x402
- Status: unknown
- Last checked: 2026-10-29
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/halowerk-sicherwerk-pkcs-12-certificate-trust-store-builder-cc9f43c4
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_FbLEpxzpe2MonNHTsw3sI

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability halowerk-sicherwerk-pkcs-12-certificate-trust-store-builder-cc9f43c4 -d '<json body>'
```

Example prompt: I need to bundle these PEM certificates into a PKCS#12 trust store — no private key, empty password — so my Java runtime will accept it: [paste PEM certs here].

## When to prefer this

Choose this endpoint when a runtime or platform strictly requires PKCS#12 format for its trust store and you only have PEM certificates (no private key). It is specifically designed for the trust-store use case (certificates only, empty password, explicit no-private-key declaration), making it safe and unambiguous for runtime consumption. Prefer it over manually invoking OpenSSL when you need a reproducible, auditable, zero-configuration conversion with a clear attestation that no private key material is present.

## Known failure modes

- Invalid or malformed PEM certificate input causes rejection
- Exceeding 16 certificates in the array returns an error
- Empty array or missing certificates_pem field fails validation
- Certificate PEM strings that are private keys or CSRs rather than certificates may be rejected
- Oversized individual PEM strings beyond 262144 characters are rejected

## How this service works

Builds a PKCS#12 container holding certificates only, for the common case where a runtime insists on PKCS#12 as its trust store format. The password is explicitly empty and reported back as such, so nothing depends on an undocumented default, and the reply states outright that the store contains no private keys. That matters: a PKCS#12 file is the usual carrier for a key, and a consumer must be able to tell a trust store from an identity store without opening it.

## Output

A PKCS#12 (.p12) binary container holding only the supplied certificates (no private keys), with an explicitly empty password. The response also states the password is empty and confirms the absence of private keys, so consumers can reliably distinguish this trust store from an identity store without inspecting the file contents.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "certificates_pem": {
   "type": "array",
   "items": {
    "type": "string",
    "maxLength": 262144,
    "minLength": 1
   },
   "maxItems": 16,
   "minItems": 1
  }
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/halowerk-sicherwerk-pkcs-12-certificate-trust-store-builder-cc9f43c4/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from sicher.halowerk.com](https://www.zero.xyz/host/sicher.halowerk.com/llms.txt)