HashiCorp GPG Key Expired: Fixing Terraform Download Errors

Over the weekend of April 18–20, 2026, CI pipelines that download Terraform started failing with openpgp: key expired. The reports piled up fast: 58 reactions and 29 comments on the Terraform tracker, another long thread on Atlantis, and parallel reports against tenv, tfswitch, and hc-install. If your pipeline was one of them — or you want to make sure the next signing-key event doesn't take your deploys down — this is what happened, what was actually affected, and the exact versions that fix it.

What happened to the HashiCorp GPG key?

HashiCorp signs release checksums with a GPG key — HashiCorp Security, key ID 72D7468F — created on April 19, 2021 with a five-year expiry. That expiry landed on April 18, 2026, at 21:50 UTC.

HashiCorp saw it coming. In February 2026 it published new self-signatures extending the same key to March 1, 2030, and on March 12 it issued security bulletin HCSEC-2026-03 stating the update was "for informational purposes only" with "no external action required."

Two details turned a non-event into a broken weekend:

1. The published key file briefly contained two key blocks — the expired signature data first, the extended one second. As a HashiCorp engineer explained in the issue wrap-up, many tools (including HashiCorp's own hc-install library) decode only the first block and never try the second.
2. Tools ship embedded copies of the key. hc-install had merged the updated key in March, but no release carried it — v0.9.3, the version embedded in Atlantis and others, still held only the pre-extension copy. When the old self-signature lapsed, every downstream tool verifying against that copy began rejecting valid releases.

One point that most threads got wrong: the key was not rotated. The fingerprint (C874 011F 0AB4 0511 0D02 1055 3436 5D94 72D7 468F) is identical before and after; only the expiration metadata changed.

What do the errors look like?

The exact strings, for matching against your CI logs:

# Atlantis, and anything else on hc-install <= 0.9.3
error downloading terraform version 1.14.8: unable to verify checksums
signature: openpgp: key expired
 
# hc-install directly
unable to verify checksums signature: openpgp: invalid message: openpgp: key expired
 
# terraform init on Terraform older than 1.6.1
Error: Failed to install provider
Error while installing hashicorp/archive v2.7.1: error checking signature:
openpgp: key expired
 
# tfswitch
Could not verify PGP signature: Signature Verification Error:
Invalid signature caused by openpgp: key expired

A local gpg --list-keys made the cause visible immediately:

pub   rsa4096 2021-04-19 [SC] [expired: 2026-04-18]

Which tools were affected, and which weren't?

The pattern: Terraform the binary was mostly fine. What broke was the installer toolchain around it — the version managers and CI bootstrappers that download and verify Terraform on every pipeline run.

How do I fix "openpgp: key expired"?

Upgrade the tool that does the downloading:

• Atlantis → v0.42.0 or later (or pre-install Terraform binaries in your image as a stopgap)
• Anything built on hc-install → rebuild with hc-install v0.9.4+
• tenv → v4.11.0+; tfswitch → v1.17.1+
• Terraform Stacks users → Terraform 1.14.9 or 1.15.x
• terraform init provider errors → upgrade Terraform to 1.6.1 or newer — and if you're running something that old, consider whether OpenTofu is the better upgrade path

If you verify releases manually, refresh your imported key — the official verification steps:

curl --remote-name https://www.hashicorp.com/.well-known/pgp-key.txt
gpg --import pgp-key.txt
gpg --verify terraform_1.14.9_SHA256SUMS.sig terraform_1.14.9_SHA256SUMS

The key file now contains a single key valid until March 1, 2030. One edge case: tools that check signature validity at the time of signing need the old-signature file to verify releases signed before February 2026 (roughly, anything older than Terraform 1.14.6).

Why did this break if HashiCorp announced it in advance?

Because an advisory can't patch embedded key copies. The March bulletin was accurate — the key was extended, nothing about the published artifacts changed — but verification happens client-side, against whatever copy of the key the client carries. The fix existed in hc-install's main branch a month before the expiry; it simply hadn't shipped in a release that downstream tools consumed. The incident window, per HashiCorp's status page, ran from the weekend reports through April 21, when the key file was reduced to the single refreshed key and the major tool releases landed.

For platform teams the lesson is less about GPG and more about inventory: the signing key turned out to be a dependency of every pipeline that downloads Terraform, and almost nobody had it on their dependency list.

Was the May apt outage related?

No. On May 15, 2026, apt.releases.hashicorp.com served an empty package index (E: Unable to locate package terraform) across all distributions for several hours. Signatures stayed valid throughout — the index files were correctly signed and empty — and HashiCorp resolved it the same day. Different failure, same takeaway: release infrastructure is part of your pipeline's dependency surface.

What's the status as of June 2026?

Verified as of June 11, 2026: the published key file contains the single extended key (expires March 1, 2030), the apt repositories are healthy, and fixed releases exist for every affected tool. Residual exposure is concentrated in pinned old versions: Atlantis images older than v0.42.0, CI bootstrap scripts on old hc-install or tfswitch, Terraform older than 1.6.1 doing provider installs, and Terraform 1.13.x Stacks users — the backport was labeled but no 1.13 patch release has shipped.

How do platform teams avoid this class of failure?

A few practices that separated the teams who noticed from the teams who paged:

• Treat installer tooling as a dependency. Pin Atlantis, tenv, tfswitch, and hc-install versions like any other dependency, and include them in upgrade sweeps. The Atlantis guide covers version management for PR-automation setups.
• Don't download on every run. Pipelines that fetch Terraform from releases.hashicorp.com on each execution multiply their exposure to release-infrastructure incidents. Bake the binary into your runner image, or use a platform that owns the toolchain — on Scalr's hosted runners, supplying the Terraform or OpenTofu version a workspace requests is the platform's responsibility rather than your pipeline's. Our CI/CD pipeline guide covers the trade-offs.
• Subscribe to status.hashicorp.com (and the security bulletins category) if any pipeline downloads HashiCorp artifacts at runtime.
• Know your init-time failure modes. Provider verification, backend configuration, and plugin installation each fail differently — the terraform init guide walks through diagnosing each stage.

The April 2026 expiry was, in the end, a well-telegraphed event that still broke a meaningful slice of the ecosystem's pipelines for a weekend. The next one is already scheduled: March 1, 2030.