This statement describes how manufactAI GmbH operates its private PKI. It follows the structure of RFC 3647 in substance rather than in full form, and describes controls that are actually implemented. It is not an audited public CA policy and makes no claim of public trust.
1. Scope
This PKI issues certificates to systems and services operated by manufactAI GmbH and to explicitly authorised partner systems, for the purpose of authenticated and mutually authenticated TLS. Certificates are trusted only by parties that have installed the root certificate published in this repository. The PKI is not audited under WebTrust or ETSI and is not intended for use outside these agreed relationships.
2. Hierarchy and key protection
| Root CA | CN=manufactAI Root CA G1. ECDSA P-384 (384 bit). Valid 2026–2046. The private key is generated in a documented key ceremony, held in a encrypted software key store kept offline, and used only to sign issuing CA certificates and the root CRL. Each ceremony is recorded and the record is retained. |
|---|---|
| Issuing CA | CN=manufactAI Issuing CA 1. ECDSA P-256 (256 bit). Valid 2026–2031. Operated online on manufactAI GmbH infrastructure; the private key is stored encrypted and is accessible only to the CA service. Rotation is planned at the latest one year before expiry. |
3. Identification and authorisation
Names are authorised before issuance. ACME issuance requires proof of control over the requested name (http-01, tls-alpn-01 or dns-01) and is technically restricted by the CA to the configured name space (currently *.manufactai.com); requests outside it are refused. Token-based issuance binds subject and SANs into a short-lived, single-use token issued by PKI operations.
4. Certificate profiles and validity
End-entity certificates are valid for at most 90 days; the default for ACME is 30 days. Keys: ECDSA P-256/P-384 or RSA ≥ 2048 bit. Extended key usage is limited to either serverAuth or clientAuth, never both. Wildcard names, code signing and S/MIME are not offered. Subscriber private keys are generated by the subscriber; the CA neither receives nor stores them.
5. Revocation and status information
Revocation requests are accepted as described on the revocation page. The CRL is regenerated on every revocation and republished in this repository; its nextUpdate provides headroom for maintenance windows rather than describing the publication delay. A root CRL, signed offline, states whether an issuing CA has been revoked. OCSP is not provided: relying parties use the CRL, and certificate lifetimes are short by design.
6. Operations and incident handling
The CA logs every request it serves; logs are available for as long as they are retained by the cluster's logging stack and are not currently exported to long-term storage. Configuration and deployment artefacts are version controlled and reviewed before rollout; the CA database is backed up regularly. If compromise of the issuing CA key is suspected, the issuing CA is revoked through the root CRL, a new issuing CA is certified, and affected subscribers are notified.
7. Changes and contact
Material changes to this statement are published here together with a new version number and effective date. PKI operations: pki@manufactai.com. Security-relevant reports (key compromise, mis-issuance) are handled with priority; please mark them as such in the subject line.