SwiftACMEKit.git · README.md

revision ccf5006d861dc0f21497db876ef26965fbcb8585 · complete file
# SwiftACMEKit

Provider-neutral Swift boundary for explicit ACME certificate lifecycle work.

This repository is currently a governed implementation scaffold. It defines the package boundary, explicit ACME
directory configuration, typed identifiers, replaceable transport/custody/challenge protocols, an HTTP-01 challenge
store, deterministic authorization/order state transitions, and JWK/JWS serialization with an injected signer
boundary, plus an offline in-memory mock order authority. Certificate issuance, SHA-256
thumbprints, real cryptographic signing, persistence, mock-server lifecycle, and Linux evidence are not implemented
yet and are not claimed.

The governing design is [Chapter 96](../Reframe-Refactoring/docs/96-swiftacmekit-is-a-provider-neutral-certificate-automation-boundary.md).
Let's Encrypt staging is a directory configuration, not the identity of the package. No production CA account,
certificate, DNS change, host installation, or secure deployment is created by this scaffold.

The package now includes a real HTTPS `URLSessionACMETransport` and explicit replay-nonce acquisition. It still
supports account registration and order creation with an injected Swift Crypto ES256 signer. It still does not
complete certificate finalization, generate CSRs, persist production keys, or install certificates; those remain typed
host-custody and lifecycle gates. HTTP-01 authorization now presents the key-authorization through the injected
challenge responder and polls the ACME authorization resource to a bounded terminal state.

The Kit also generates SAN-bound PKCS#10 requests and can finalize an order and persist the returned PEM chain through
the injected certificate store. Renewal, revocation, and live CA staging evidence remain separate release gates.