hoike CLI Reference

The hoike binary is the main entry point for the OCSP responder. It provides five subcommands: serve, check, sign, import, and query.

Global options

hoike [OPTIONS] <COMMAND>

Option	Description
`--version`	Print version information
`--help`	Print help

hoike serve

Start the OCSP responder server.

hoike serve --config <PATH>

Options

Flag	Required	Default	Description
`--config <PATH>`	Yes	–	Path to the `hoike.toml` configuration file

Description

Starts the axum-based HTTP server that serves pre-signed OCSP responses from loaded ahu bundles. The server operates in the mode specified in the configuration file (edge, signer, or combined).

In edge mode, the server memory-maps bundle files and serves responses at memory-read speed with no cryptographic work at request time.

If gossip is enabled in the configuration, the server also starts a SWIM protocol listener for fleet coordination and bundle distribution.

Example

hoike serve --config /etc/hoike/hoike.toml

hoike check

Validate configuration, bundles, and connectivity without starting the server.

hoike check --config <PATH>

Options

Flag	Required	Default	Description
`--config <PATH>`	Yes	–	Path to the `hoike.toml` configuration file

Description

Performs a comprehensive pre-flight check:

Config parsing – validates the TOML configuration syntax and structure
Bundle verification – for each configured [[ca]] entry, verifies the referenced bundle file exists and passes seal verification
Storage access – confirms bundle_dir and state_db directories exist and are writable
Gossip connectivity – if gossip is enabled, attempts to resolve and connect to seed nodes

Reports issues with clear error messages. Exit code 0 on success, non-zero on failure.

Example

hoike check --config /etc/hoike/hoike.toml

hoike sign

Produce a signed ahu bundle from a CRL and optional good-serials list.

hoike sign --ca <LABEL> --crl <FILE> [OPTIONS]

Options

Flag	Required	Default	Description
`--ca <LABEL>`	Yes	–	CA scope label for the bundle
`--crl <FILE>`	Yes	–	Path to the CRL file (PEM or DER)
`--signing-key <FILE>`	*	–	PKCS#8 PEM/DER signing key. Mutually exclusive with `--demo-key`.
`--demo-key`	*	false	Use an ephemeral key (testing only). Mutually exclusive with `--signing-key`.
`-o <FILE>`	No	`output.ahu`	Output bundle file path
`--sig-alg <ALG>`	No	`ecdsa-p256`	Signature algorithm (see below)
`--certid-compat <MODE>`	No	`dual`	CertID hash compatibility mode (see below)
`--epoch <N>`	No	`1`	Epoch number for anti-rollback
`--good-serials <FILE>`	No	–	File of hex serial numbers to mark as good
`--issuer-name-b64 <B64>`	No	–	Base64-encoded DER issuer name for correct CertID hashes
`--issuer-key-b64 <B64>`	No	–	Base64-encoded issuer public key bytes
`--issuer <FILE>`	No	–	Issuer certificate (DER) for automatic CertID computation
`--seal-key <FILE>`	No	–	PKCS#8 PEM/DER seal key file (separate from signing key)
`--dual-alg <ALG>`	No	–	Produce a dual-algorithm bundle alongside `--sig-alg` (e.g., `ml-dsa-87`)
`--pq-signing-key <FILE>`	No	–	PKCS#8 PEM/DER PQ signing key file (required with `--dual-alg`)

* One of --signing-key or --demo-key is required. hoike refuses to sign without an explicit key source.

Signature algorithms (`--sig-alg`)

Value	Algorithm	Key type
`ecdsa-p256`	ECDSA with P-256/SHA-256	EC P-256
`ml-dsa-44`	ML-DSA-44 (FIPS 204)	ML-DSA-44
`ml-dsa-65`	ML-DSA-65 (FIPS 204)	ML-DSA-65
`ml-dsa-87`	ML-DSA-87 (FIPS 204)	ML-DSA-87

The ML-DSA algorithms provide post-quantum signing. Use these when your PKI deployment requires quantum-resistant certificate status.

CertID compatibility (`--certid-compat`)

Value	Behavior
`dual`	Produce both SHA-256 and SHA-1 CertID entries for each certificate. Maximizes client compatibility.
`sha256`	SHA-256 CertID entries only. Standards-compliant but may not work with older clients.
`sha1`	SHA-1 CertID entries only. Legacy compatibility mode.

Good-serials file format

A plain text file with one hex-encoded serial number per line:

01A3F2
01A3F3
01B7C0

Certificates listed here are marked as good in the OCSP responses. Certificates found in the CRL are marked as revoked. Certificates in neither list are treated according to the CA’s completeness policy.

Epoch numbering

The epoch is a monotonically increasing integer that prevents rollback attacks. Edge nodes refuse to load a bundle with an epoch lower than the currently loaded one. If --epoch is not specified, the signer auto-increments from the previous bundle’s epoch.

Example

# Production (with PKCS#8 key file)
hoike sign \
  --ca enterprise-issuing-01 \
  --crl /var/lib/pki/ca.crl \
  --signing-key /etc/pki/ocsp-signer.key \
  --good-serials /var/lib/pki/good-serials.txt \
  --sig-alg ecdsa-p256 \
  --certid-compat dual \
  --epoch 42 \
  -o /var/lib/hoike/bundles/enterprise.ahu

# Testing (with demo key)
hoike sign \
  --ca test-ca \
  --crl test.crl \
  --demo-key \
  -o test.ahu

hoike import

Import a bundle for air-gap or enclave deployments where gossip is not available.

hoike import --bundle <PATH> [OPTIONS]

Options

Flag	Required	Default	Description
`--bundle <PATH>`	Yes	–	Path to the ahu bundle file to import
`--config <PATH>`	No	–	Path to hoike.toml (for target directory resolution)
`--force`	No	false	Skip epoch and seal checks during import

Description

Copies an ahu bundle into the configured bundle directory and registers it with the state database. This is the manual alternative to gossip-based bundle distribution.

The import process:

Verifies the bundle seal and integrity
Checks that the epoch is greater than any currently loaded bundle for the same CA scope
Copies the bundle to bundle_dir
Updates the state database

Use --force to bypass epoch and seal checks (for disaster recovery or initial bootstrap only).

Example

# Standard import
hoike import --bundle /mnt/usb/enterprise.ahu \
  --config /etc/hoike/hoike.toml

# Force import (disaster recovery)
hoike import --bundle /mnt/usb/enterprise.ahu \
  --config /etc/hoike/hoike.toml --force

hoike query

Query a running OCSP responder with optional algorithm preference negotiation.

hoike query --url <URL> --serial <HEX> --issuer-name-b64 <B64> --issuer-key-b64 <B64> [OPTIONS]

Options

Flag	Required	Default	Description
`--url <URL>`	Yes	–	Responder URL (e.g., `http://localhost:2560`)
`--serial <HEX>`	Yes	–	Hex-encoded certificate serial number
`--issuer-name-b64 <B64>`	Yes	–	Base64-encoded DER issuer name
`--issuer-key-b64 <B64>`	Yes	–	Base64-encoded issuer public key bytes
`--prefer <ALGS>`	No	–	Comma-separated preferred algorithms (e.g., `ml-dsa-87,ecdsa-p256`)

Description

Builds an OCSP request for the given serial number and issuer, sends it to the specified responder, and displays the parsed response including status, signature algorithm, timestamps, and nonce handling.

When --prefer is specified, the request includes an RFC 6960 §4.4.7.1 PreferredSignatureAlgorithms extension. This is used to test dual-algorithm bundle negotiation — requesting ml-dsa-87 from a responder serving a dual-algorithm bundle returns the ML-DSA response.

Example

# Basic query
hoike query \
  --url http://localhost:2560 \
  --serial 0A1B2C \
  --issuer-name-b64 "..." \
  --issuer-key-b64 "..."

# Query with post-quantum preference
hoike query \
  --url http://localhost:2560 \
  --serial 0A1B2C \
  --issuer-name-b64 "..." \
  --issuer-key-b64 "..." \
  --prefer ml-dsa-87

Keyboard shortcuts

hoike documentation