Learn PKI - Modern Features & Roadmap

#Introduction

Episode 20 took us to post-quantum cryptography and modern trends. But theory is only useful if the tools you use truly follow it. A fair question arises: does the OpenSSL I installed already support ML-DSA? What about the cert-manager and step-ca I use in production? And where is this industry heading in 2026?

Episode 21 answers all of that. We dissect the roadmaps of the three tools most used throughout this series — OpenSSL, cert-manager, and step-ca — complete with the version numbers and support policies in effect today, then close with three big 2026 trends: mandatory mTLS in Kubernetes, standardized post-quantum TLS, and PKI-as-code.

#OpenSSL 4.0 and the Release Strategy

OpenSSL has a release pattern that is important to understand so you do not pick the wrong version. Mainline versions such as 4.0 are released with the latest features, but are short-lived — supported for about thirteen months. Long Term Support, or LTS, versions live for years and receive security backports, and are therefore the primary choice for production.

The major OpenSSL 4.0 release arrived in April 2026, and its latest update, OpenSSL 4.0.1, was released in June 2026 with fixes for several CVEs in the PKCS7, CMS, and QUIC areas. If you are already using 4.0, upgrade to 4.0.1 soon. But remember: 4.0 is mainline, not LTS — for workloads needing long-term stability, 3.5 LTS remains the main recommendation.

openssl version -a

Check your version now: openssl version is enough to know the build number, while -a shows compilation details, release date, and configuration directory.

#The Support Map You Need to Know

To avoid confusion among versions, here is the support map in effect:

• OpenSSL 3.0 LTS officially ends in September 2026. If you are still using it, this is the last safe moment to migrate.
• OpenSSL 3.5 LTS remains recommended for production, with support until April 2030. Stable, tested, and receives security backports.
• OpenSSL 4.0 is the latest mainline with about thirteen months of support, suitable for those who need the newest features and regularly follow releases.

#Safe Upgrade Habits

Changing OpenSSL versions cannot be done without a plan. First, read the changelog to see changes in default behavior — sometimes parameters that were once loose are now tightened, and that can break handshakes that were working. Second, test the entire suite of applications depending on TLS in staging, including old clients using deprecated ciphers.

Third, prepare a rollback path. With a package manager, keep the previous version or use a restorable image, like the Docker pattern you already know from the early episodes. Finally, monitor for several days after the upgrade, not just when the process finishes. Cryptographic behavior often only shows up under high load or when a rare connection tries a handshake.

#Providers and Post-quantum in OpenSSL 4.0

OpenSSL 4.0 continues the provider architecture we discussed in episode 20. Post-quantum support is accessed through additional providers, so the core library stays lean and adopting new algorithms does not wait for the next major release. ML-KEM, ML-DSA, and SLH-DSA are available as providers and can already be used for hybrid handshakes and certificate signatures.

openssl list -providers
openssl list -kem-algorithms | rg -i mlkem

For operators, this means post-quantum capability no longer depends on the OpenSSL version, but on the providers you install. Provider policy can be configured per application through configuration, so the gradual transition we designed in episode 20 can run per service, not all at once.

#cert-manager 1.21

cert-manager keeps moving fast. Release 1.21 brings ACME profiles, which let you define standard certificate profiles — validity, algorithm, and extensions — then reuse the same profile across many Certificates. This removes configuration duplication and makes policy consistent across the cluster.

Short-lived certificate support is also maturing: Certificates with very short validity fully leverage ACME automation, exactly as we discussed in episode 20. Just as important, the ExternalIssuer ecosystem keeps growing — third-party providers connecting cert-manager to any CA, from step-ca and Vault to enterprise-class HSMs, through one identical API.

helm upgrade cert-manager jetstack/cert-manager \
  --namespace cert-manager --version v1.21.0
kubectl apply -f cluster-issuer-stepca.yaml

mTLS automation is also becoming a focus: service mesh and workloads use identities from cert-manager to authenticate each other, and this supports the industry direction we see in the 2026 trends.

#step-ca 0.30

On the step-ca side, release 0.30 brings refinements to provisioner management, including better flows for issuing mTLS and short-lived certificates. The production qualities we built in episodes 9 and 18 — HA, HSM, and distribution — continue to be strengthened as the foundation.

step version
step ca health

step-ca's roadmap points toward post-quantum adoption and deeper integration with trust-manager, the project managing trust bundle distribution across the cluster — exactly the need from episode 5 about root certificate distribution. With trust-manager, CA bundles are distributed as centrally managed artifacts, and step-ca becomes their supplier.

For those joining mid-journey, both tools can be learned from episodes 9 and 10 as a foundation, then episodes 18 and 19 for the HA and monitoring sides. The cert-manager and step-ca combination covers almost all modern identity needs — from application certificates, mTLS between services, to SSH certificates.

#2026 Trend: Mandatory mTLS in Kubernetes

The year 2026 marks a big step: mTLS becomes the default requirement on many Kubernetes platforms, especially via the Gateway API. If mTLS used to be an add-on setting for the diligent, it is now part of policy enforced at the API gateway level, not in each application.

With this approach, every service has an identity verified before traffic is allowed in. Kubernetes deployments are required to have a valid workload identity — provided by cert-manager and issuers such as step-ca — so a cluster without tidy certificate management will be clearly visible during audits.

#2026 Trend: Standardized Post-quantum TLS

The post-quantum standards we discussed in episode 20 are now entering the real adoption phase. Browsers, CDNs, and major TLS libraries are starting to enable hybrid handshakes by default, and NIST continues finalizing interoperability details for post-quantum certificates and signatures. The hope is that within a few years, fully post-quantum certificate chains become ordinary.

ssl_conf:
  system_default:
    options: default
    groups: X25519MLKEM768:MLKEM768

Networks that do not support hybrid groups still work normally — the handshake falls back to classical algorithms automatically. That is the beauty of hybrid: future-safe without breaking today's compatibility.

All operators need to prepare is configuring the group list on the server and client sides. Because the hybrid handshake negotiates automatically, you do not need to change applications one by one — just make sure the TLS library version is new enough, then enable hybrid groups in the system configuration.

#2026 Trend: PKI-as-code

Finally, PKI-as-code is becoming a more accepted pattern: all PKI configuration — root, intermediate, issuer, certificates, even validity policy — is managed as code in git, applied through Terraform and GitOps as we built in episode 19. This brings all the goodness of Infrastructure as Code to the digital identity world.

Reproducibility is the key: a new cluster is built with an already-defined PKI, not assembled manually. Auditing becomes easy because every change has a trace. And most importantly, PKI-as-code makes identity security part of the development workflow, not a separate daunting task.

Combine it with the alerting from episode 19 and the post-quantum adoption from episode 20, and you have a foundation that can grow: policy changes just through a pull request, monitored automatically, and ready for whatever algorithm comes next.

#Closing

Episode 21 maps the road ahead: OpenSSL 4.0.1 with CVE fixes in PKCS7, CMS, and QUIC, a clear LTS policy — 3.5 until April 2030, 3.0 ending September 2026 — cert-manager 1.21 features with ACME profiles and ExternalIssuer, step-ca 0.30 heading toward post-quantum and trust-manager, and three big 2026 trends: mandatory mTLS, post-quantum TLS, and PKI-as-code.

Key takeaways:

• OpenSSL 4.0 is a short-lived mainline; use 3.5 LTS for production and leave 3.0 soon.
• Post-quantum support in OpenSSL arrives through providers, so it can be adopted per service.
• cert-manager 1.21 makes consistency easier with ACME profiles and the ExternalIssuer ecosystem.
• step-ca 0.30 strengthens automated mTLS and connects with trust-manager for bundle distribution.
• 2026 makes mTLS, post-quantum TLS, and PKI-as-code standards to follow.

This is the last episode on tools and trends. In episode 22 we pause for a moment and look at the whole map: comparing all the PKI ecosystems we have known, when to use which, a full recap of this journey, and a production checklist. See you there!