Cloudflare’s apt repository causing GPG key errors on your Debian/Ubuntu servers again? I’ll walk you through the root cause and three real-world solutions to fix the ‘cloudflare.list’ error and get your deployments back on track.

“Here We Go Again…” – Fixing the Cloudflare `apt` GPG Error For Good

I still remember the feeling. It was 2 AM, and we were rolling out an emergency patch for a nasty RCE vulnerability across our entire web fleet. The Ansible playbook was chugging along nicely… until it hit the `apt update` task. Suddenly, my screen was a sea of red. GPG error: https://pkg.cloudflare.com/cloudflared focal InRelease: The following signatures were invalid: EXPKEYSIG.... The deployment ground to a halt on `prod-web-01`, and my heart sank. A simple, external repository issue was blocking a critical security patch. It’s a scenario every ops engineer dreads, and it’s exactly what happens when upstream providers change their signing keys.

So, What’s Actually Breaking?

Before we jump into the fixes, let’s take 30 seconds to understand the “why”. This isn’t a bug; it’s a security feature doing its job, albeit at the worst possible time. Your server’s package manager (apt for Debian/Ubuntu) uses GPG keys to cryptographically verify that the packages you’re about to install from a repository are legit and haven’t been tampered with. Think of it as a digital bouncer checking the ID of every package that tries to get onto your server.

When Cloudflare (or any provider) updates their repository’s signing key, the old key your server trusts is no longer valid. The bouncer sees a new ID it doesn’t recognize and throws an error, refusing to trust anything from that source. Our job is to give the bouncer the new, updated guest list.

The Solutions: From Quick Fix to Permanent Cure

I’ve seen this happen enough times to have a playbook. Depending on your situation—whether you’re trying to save a single failing server or fix your entire infrastructure—one of these will be the right tool for the job.

Solution 1: The “Get Me Out of This” Quick Fix

This is the manual, “I’m SSH’d into a burning server and need it fixed now” approach. It’s perfect for a single machine or for testing the fix before you automate it.

We’re essentially going to manually download the new GPG key and tell `apt` where to find it.

# First, create the directory for apt keys if it doesn't exist
sudo mkdir -p /usr/share/keyrings

# Next, download the new GPG key from Cloudflare and place it there
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null

# Now, run your update. The error should be gone.
sudo apt-get update

Pro Tip: You might also need to update your /etc/apt/sources.list.d/cloudflare.list file to explicitly point to the new key. It should look like this:

deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared your_distro_codename main

Just replace your_distro_codename with `focal`, `jammy`, etc.

Solution 2: The “Do It Right” Permanent Fix (Automation)

Doing this manually on one server is fine. Doing it on 200 is a nightmare. As a senior engineer, your first thought should be: “How do I automate this so it never pesters my team again?” This is where Infrastructure as Code (IaC) tools like Ansible, Puppet, or Salt come in.

Here’s how I’d fix this in our Ansible playbook. This ensures every server we build or configure from now on gets the correct key, and we can re-run it on existing fleets to fix them all at once.

This Ansible task is idempotent, meaning you can run it a thousand times, and it will only make changes if necessary.

- name: Add Cloudflare GPG key
  ansible.builtin.get_url:
    url: https://pkg.cloudflare.com/cloudflare-main.gpg
    dest: /usr/share/keyrings/cloudflare-main.gpg
    mode: '0644'
    force: true

- name: Add Cloudflare repository
  ansible.builtin.apt_repository:
    repo: "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared {{ ansible_distribution_release }} main"
    state: present
    filename: cloudflare

This is the real solution. You fix it in code, commit it to git, and the problem is solved for good, across your entire infrastructure. No more 2 AM panics.

Solution 3: The “Break Glass” Nuclear Option

Okay, let’s be honest. Sometimes you’re in a situation so critical that you just need the package installed, and you’re willing to accept temporary risk. Maybe the new key URL is down, but you have a cached copy of the package you trust. This is the “I’m desperate” option.

A HUGE WARNING: This approach completely disables signature verification for the Cloudflare repository. You are telling your server to blindly trust and install ANYTHING from that URL. Use this only as a last resort to get a critical system online, and revert it immediately afterward.

You edit the repository file directly:

# Edit this file:
sudo nano /etc/apt/sources.list.d/cloudflare.list

# Change this line:
# deb https://pkg.cloudflare.com/cloudflared focal main

# To this (add [trusted=yes]):
# deb [trusted=yes] https://pkg.cloudflare.com/cloudflared focal main

After making this change, `sudo apt-get update` will succeed, but with a warning. Again, this is a “hacky” fix for an emergency. Don’t leave your systems configured like this.

Comparing The Approaches

At the end of the day, these kinds of outages are a reminder that even in the cloud, we’re building on layers of dependencies. The key isn’t to never have problems, but to have a solid, practiced plan for when they inevitably do. Now go fix your playbook!

– Darian Vance, Senior DevOps Engineer, TechResolve

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions