October 2026 Summaries

HashiCorp has deprecated the GitHub-maintained, source-available Community Edition of Boundary, archiving its repository and stating that future research and development will focus on the commercial Enterprise and HCP offerings. The announcement, made without advance notice or detailed justification, prompted concerns among users who may now need to purchase enterprise licenses, assume maintenance of the software, or migrate to alternatives. The piece links the decision to HashiCorp’s direction since IBM acquired the company in February 2025, citing discontinued lower-cost plans and hosted services, stricter Terraform pricing, reported support issues, and a broader emphasis on large enterprise customers. It argues that Boundary’s deprecation could raise questions for users of other HashiCorp community products, while acknowledging that possible future removals of Vault or Terraform community editions are speculative. The post ultimately promotes Infisical’s open-source secrets management, certificate management, and privileged access management products as alternatives to HashiCorp Vault and Boundary.

The CA/Browser Forum plans to reduce the maximum validity of publicly trusted TLS certificates from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029, with domain validation reuse limited to 10 days at the final stage. The changes apply to public-facing certificates for services such as websites, APIs, mail servers, VPNs, CDNs, and browser-accessible appliances, while privately operated internal certificate authorities remain outside the policy. The text argues that increasingly frequent renewals will make manual certificate tracking costly and prone to outages, particularly when certificates lack clear ownership, are distributed across multiple platforms, fail to trigger service reloads, or rely on infrastructure without ACME support. It recommends creating a centralized certificate inventory through endpoint scanning, automating issuance and deployment where possible, monitoring the certificates actually served to clients, addressing legacy-device exceptions, testing renewal processes, and preparing a backup certificate authority. It also presents Infisical Certificate Management as a tool intended to centralize discovery, issuance, renewal, deployment integrations, and alerts across multiple certificate systems and protocols.

Microsoft Active Directory Certificate Services (AD CS) remains a widely used Windows-based PKI because it integrates with Active Directory, certificate templates, Group Policy auto-enrollment, smart cards, VPNs, Wi-Fi, and internal services, but its domain-centric design creates challenges for Linux, Kubernetes, cloud platforms, mobile devices, and DevOps pipelines. Its main limitations include lacking native ACME and EST support, relying on constrained NDES/SCEP workflows, offering little automation beyond domain-joined Windows devices, requiring additional Windows infrastructure to scale, and providing no unified certificate inventory or multi-cloud lifecycle management. Organizations can either replace AD CS with modern private CAs such as EJBCA, HashiCorp Vault, step-ca, or AWS Private CA, or retain it for Windows-dependent use cases while adding a certificate lifecycle management platform. The text presents Infisical as an example of the latter approach, using a network gateway to connect AD CS with ACME, EST, SCEP, and API-based enrollment, centralizing discovery, renewal, alerts, and deployment across cloud services while preserving existing trust chains and Windows auto-enrollment.

On-premises workloads often lack the native machine-identity integration available in AWS, GCP, and Azure, leading some organizations—particularly those operating regulated or self-managed infrastructure—to rely on hardcoded credentials despite their security risks. The approach described uses a Trusted Platform Module (TPM) or virtual TPM as a hardware-rooted identity, SPIFFE/SPIRE to attest machines and issue short-lived SPIFFE Verifiable Identity Documents (SVIDs) or JWTs, and Infisical to provide authenticated access to secrets. A SPIRE server validates TPM endorsement-key hashes, while agents on virtual machines authenticate to the server and can issue identities scoped not only to a host but also to a specific systemd service through workload selectors. The walkthrough outlines configuring SPIRE server and agent binaries, TPM attestation plugins, trust bundles, systemd services, node and workload registration, and JWT-based login to Infisical. This model avoids storing long-lived secrets on machines, automatically renews credentials, and restricts secret access to verified workloads, aiming to replicate cloud-style machine authentication on self-managed hardware.

Windows certificate management involves installing, storing, binding, renewing, and retiring X.509 certificates used by services such as IIS, Remote Desktop, Exchange, SQL Server, and WinRM, along with trusted root and intermediate certificates. On IIS servers, service certificates must be stored in the local machine certificate store with their private keys, while HTTPS bindings are maintained by HTTP.sys and reference a specific certificate thumbprint; therefore, replacing a certificate requires updating each relevant binding. Common renewal problems include importing certificates into the user rather than machine store, missing private keys, old bindings continuing to reference expired certificates, autoenrollment behavior, private-key permission issues, and complications across web farms or mixed SNI and IP-based bindings. IIS generally does not require a restart after bindings change, but manually renewing and rebinding certificates becomes difficult to manage as certificate lifetimes shorten and infrastructure grows. Automation options include per-server ACME clients such as win-acme, which can request, install, and rebind public certificates, or centralized certificate-management systems that issue, renew, distribute, import, and rebind certificates across multiple servers and environments.

Enterprise certificate management becomes complex not merely because of volume but because certificates are issued by multiple public, private, cloud, Kubernetes, and self-signed sources, deployed across diverse infrastructure, and owned by different teams with inconsistent visibility and permissions. Shortening public TLS certificate lifetimes, reaching 47 days by 2029 under CA/Browser Forum rules, will increase renewal demands and make manual processes less viable. Effective management therefore requires a centralized layer for discovery, inventory, policy enforcement, audit records, renewal coordination, and role-based access, without necessarily replacing existing certificate authorities. The approach separates policy administration from routine issuance, defines boundaries between environments or regions through distinct CAs and enrollment endpoints, limits certificate attributes such as names, validity periods, algorithms, and usages, and gives automated pipelines narrowly scoped identities. Auditors need read-only access to complete records of certificates, policies, issuers, approvals, revocations, and deployment locations, while approvals should be reserved for higher-risk cases rather than broadly applied to automation. Migration can proceed gradually by discovering the existing estate, establishing new policies alongside current systems, moving lower-risk services first, and shifting production renewals over time. Infisical is presented as a certificate-management platform that connects to existing issuers, discovers deployed certificates, applies centralized policies and delegated roles, supports common enrollment protocols, and distributes certificates to infrastructure destinations.