HashiCorp Vault PKI Secrets Engine for an Internal Certificate Authority

Internal certificate authorities underpin a huge amount of enterprise traffic. From mutual TLS between microservices in a Sydney data centre to signed device certificates for staff working remotely from Melbourne or Brisbane, organisations routinely need to issue, rotate, and revoke X.509 material without paying a public CA for every short-lived credential. HashiCorp Vault offers a dedicated PKI secrets engine that treats certificates as ephemeral secrets, tightly bound to policies and short TTLs, rather than as static files stored on a file share.

The engine fits naturally into a hybrid IT environment because the same Vault cluster can serve workloads hosted in AWS Asia Pacific (Sydney), an on-premises VMware estate, and developer laptops connecting over a corporate VPN. For Australian practitioners, the appeal extends beyond convenience: stronger lifecycle control helps satisfy the ACSC Information Security Manual and the Essential Eight mitigation strategies, both of which expect demonstrable certificate rotation and revocation discipline.

Initialising the PKI Secrets Engine

The first operational step is enabling the engine at a dedicated path, for example pki-int, with a sensible maximum lease TTL tuned to the longest certificate lifetime the organisation is comfortable issuing. A second engine is usually mounted at pki-root so the root CA stays offline and air-gapped, while intermediates remain online to sign leaf certificates. Mounting the engines separately gives clear blast-radius separation, since compromising the issuing path does not expose the root private key.

Storage backends should be reviewed with an eye to performance and locality. Australian teams running integrated Raft storage or HSM-integrated Transit will want to confirm that encryption keys are held in regions that meet their data sovereignty requirements. A typical production layout places the Vault cluster in ap-southeast-2 for Sydney workloads, with disaster recovery nodes in Melbourne.

Building the Internal Certificate Authority Hierarchy

Once the engines are mounted, the root CA is generated using pki-root/root/generate/internal, exported as a certificate, then the engine is sealed by revoking the root or simply disabling the path. The intermediate CA is then produced on the offline root and its signing request imported into the online pki-int engine. This mirrors the well-established practice of keeping root material on a token-protected workstation while intermediates handle the day-to-day signing workload.

Most Australian organisations also generate a CRL and OCSP responder configuration at this stage. Even for purely internal use, tying certificates into monitoring dashboards in Sydney-based SOC tooling means that a misissued cert surfaces quickly. URL templates for issuing and CRL endpoints should be reachable from every site, including remote branch offices connected through AARNet or commercial MPLS circuits.

Defining Roles for Service and User Certificates

Vault PKI roles act as named policies that constrain what a certificate can be used for, who can request it, and what its TTL can be. A common pattern is one role per application, for example payments-api-tls, with allowed domains restricted to the service's internal DNS namespace. Another role might cover VPN client certificates, with client_flag enabled and key_type set to RSA or EC depending on what the remote access gateway supports.

Practitioners in regulated industries often add extra constraints. A role used by a financial services team subject to APRA CPS 234 can mandate key strengths, allowed uses, and minimum TTLs that map directly to control evidence. Naming conventions matter too: roles like syd-cluster-mesh or mel-payments-svc make audit queries much easier when the security team in Canberra needs to reconcile Vault activity against broader change records.

Issuing, Renewing, and Revoking Certificates

Certificates are requested through pki-int/issue/<role> and returned with private key, certificate, and CA chain in a single response. Many teams wrap these calls in helper scripts that push the resulting PEM bundle straight into the application's keystore or Kubernetes secret, removing any chance of the private key being written to disk in plaintext. With short TTLs of 24 to 72 hours, renewal becomes routine rather than alarming.

Revocation flows deserve the same rigour. Vault maintains a CRL per issuing engine, and pki-int/revoke can be called manually or wired into an automated response when a workload is decommissioned. For Australian compliance teams operating under the Notifiable Data Breaches scheme, fast, auditable revocation is valuable evidence that credential exposure is being contained rather than left to linger.

Policy and Access Governance

The PKI engine is only as secure as the ACLs in front of it. A baseline policy grants read-only access to the CA chain for everyone, while write and update capabilities are limited to specific service identities. Sensitive operations such as generating root CAs or tuning TTLs should require sudo capabilities and dual-control approvals, mirroring the separation of duties described in the Australian Government Information Security Manual.

Token lifetimes should be short, with periodic tokens preferred for automated issuance from CI runners and batch tokens reserved for ephemeral build jobs. Audit logs from the PKI paths feed directly into the SIEM, and structured log shipping to an ap-southeast-2 platform in Sydney means the SOC can correlate certificate events with network telemetry in near real time.

Automation and Integration with Pipelines

HashiCorp's tooling, plus a healthy ecosystem of community providers, makes it straightforward to call the PKI engine from Terraform, Ansible, or CI platforms. A typical pattern is to have pipelines authenticate to Vault using short-lived AppRole credentials before requesting certificates for newly built container images or load balancer listeners. Because Vault issues credentials at request time, build agents in Brisbane or Perth do not need to share a static signing key.

Radware load balancers and reverse proxies commonly front internal APIs, and many Australian integrators rely on Vault to bootstrap their TLS profiles during cluster bring-up. Treating certificates as just another dynamic secret removes the temptation to bake long-lived PEM files into container layers, which is one of the most common sources of certificate-related outages.

Aligning Internal PKI with Australian Compliance

Running your own certificate authority carries responsibilities that intersect with several Australian regulatory regimes. The Privacy Act 1988 expects personal data, including data carried over TLS, to be protected by reasonable safeguards, while APRA-regulated entities must demonstrate control effectiveness under CPS 234. Internal PKI deployed with Vault gives auditors concrete artefacts: short TTLs, logged issuance, enforced revocation, and policy-bound roles.

Documentation should reference the ACSC Information Security Manual and the Essential Eight, particularly the patching and application control mitigations, because a compromised certificate authority undermines both. For organisations operating across state borders, scheduling nightly CRL publication and rotation jobs in AEST rather than the default UTC keeps on-call rotations in Sydney, Melbourne, and Brisbane aligned with the rest of the operational calendar.