How to fix gpg: WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner in Git

GitINTERMEDIATELOWUpdated Dec 2, 2025· 180 views

This GPG warning appears when verifying signed Git commits or tags when the signing key is not in your web of trust. The signature is cryptographically valid, but GPG cannot confirm who owns the key. Fix this by signing the key or setting its trust level.

Quick fix

Fixes gpg: WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner

# Verify a specific commit
git verify-commit HEAD

# Or check signatures in log
git log --show-signature -1
  1. Verify the signature is actually valid
  2. Import and verify the signer's key
  3. Sign the key (recommended for known identities)
  4. Set trust level without signing
git — error
# Verify a specific commit
git verify-commit HEAD
# Or check signatures in log
git log --show-signature -1
gpg: WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner

What this error means

The "gpg: WARNING: This key is not certified with a trusted signature!" warning indicates that while GPG can verify the signature is cryptographically valid (the data hasn't been tampered with), it cannot confirm that the key actually belongs to the person it claims to represent. This is a fundamental concept in GPG's web of trust model. Just having someone's public key in your keyring doesn't mean you trust their identity. GPG requires a "trust path" - either you've personally verified and signed their key, or someone whose key you've signed has signed their key. When verifying Git commits or tags, Git uses GPG to check signatures. If the key isn't in your web of trust, GPG shows this warning. Importantly, this is a WARNING, not an ERROR. The signature verification still succeeds (exit code 0), and the commit/tag is marked with "U" (good signature, unknown validity) rather than "G" (good signature, valid key). This warning is expected behavior when: - You've imported someone's public key but haven't signed it - You're verifying commits from a colleague whose key you haven't formally verified - You're checking signatures from open source maintainers you've never met - You cloned a repository with signed commits but don't have the signers' keys in your trust chain

Typical symptoms

  • GPG shows 'WARNING: This key is not certified with a trusted signature' when verifying commits
  • Git verify-commit or verify-tag shows 'Good signature' but also displays the warning
  • GitHub/GitLab shows commits as 'Verified' but local verification shows the warning
  • The warning appears even though you have the signer's public key imported
  • Git log --show-signature shows 'U' status instead of 'G' for commits
  • CI/CD pipelines report signature verification warnings despite valid signatures

Common causes

  1. The public key is imported but not signed or trusted by you (most common)
  2. No trust path exists between your GPG key and the signer's key
  3. You haven't set an owner trust level for the key
  4. The key was imported automatically but never verified against the owner's identity
  5. You're using the default 'pgp' trust model which requires key signatures
  6. The key exists in your keyring but has expired certifications

How to fix "gpg: WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner"

1Verify the signature is actually valid

First, confirm that this is just a trust warning and not an actual signature problem:

Check commit signature:

bash
# Verify a specific commit
git verify-commit HEAD

# Or check signatures in log
git log --show-signature -1

Check tag signature:

bash
git verify-tag v1.0.0

Understanding the output:
- "Good signature" = cryptographically valid (file not tampered)
- WARNING about trust = identity not verified in your web of trust
- Exit code 0 = verification succeeded

Check GPG's assessment:

bash
# Get the key ID from the signature output, then:
gpg --list-keys <KEY_ID>

# Check trust level
gpg --list-keys --with-colons <KEY_ID> | grep -E "^(pub|uid)"

The warning is informational - your commit is legitimately signed, you just haven't verified the signer's identity.

2Import and verify the signer's key

If you don't have the key, import it first:

From a keyserver:

bash
# Search for key by email
gpg --keyserver keyserver.ubuntu.com --search-keys user@example.com

# Or import by key ID
gpg --keyserver keyserver.ubuntu.com --recv-keys <KEY_ID>

From GitHub/GitLab:

bash
# GitHub: https://github.com/<username>.gpg
curl https://github.com/torvalds.gpg | gpg --import

# GitLab: https://gitlab.com/<username>.gpg
curl https://gitlab.com/username.gpg | gpg --import

Verify the fingerprint:
Before trusting a key, verify its fingerprint through a trusted channel (in person, video call, trusted website):

bash
# Show full fingerprint
gpg --fingerprint <KEY_ID>

# Compare with fingerprint published on:
# - User's personal website (over HTTPS)
# - Official project documentation
# - In-person verification
3Sign the key (recommended for known identities)

If you've verified the key belongs to who it claims (e.g., a coworker you know), sign it:

Interactive signing:

bash
gpg --edit-key <KEY_ID>
# At the gpg> prompt:
gpg> sign
# Confirm with 'y'
gpg> save

Local signing (doesn't export to keyservers):

bash
gpg --edit-key <KEY_ID>
gpg> lsign
gpg> save

Non-interactive local signing:

bash
gpg --quick-lsign-key <KEY_ID>

The difference:
- sign = certification can be exported and shared
- lsign = certification stays on your machine only (safer for casual trust)

After signing, the warning will disappear for commits signed by this key.

4Set trust level without signing

If you trust a key but don't want to sign it (perhaps you can't verify identity but trust the source):

Interactive trust setting:

bash
gpg --edit-key <KEY_ID>
# At the gpg> prompt:
gpg> trust
# Select trust level:
# 1 = I don't know or won't say
# 2 = I do NOT trust
# 3 = I trust marginally
# 4 = I trust fully
# 5 = I trust ultimately (use only for your own keys)
# Choose 4 for most cases
gpg> quit

Non-interactive trust setting:

bash
# Get the fingerprint
FINGERPRINT=$(gpg --fingerprint <KEY_ID> | grep -A1 "pub" | tail -1 | tr -d ' ')

# Set trust level (format: fingerprint:trust_level:)
echo "${FINGERPRINT}:4:" | gpg --import-ownertrust

Alternative: Add to gpg.conf:

bash
# Add to ~/.gnupg/gpg.conf
echo "trusted-key <LONG_KEY_ID>" >> ~/.gnupg/gpg.conf

This marks the key as ultimately trusted (equivalent to trust level 5).

5Use alternative trust models

GPG supports different trust models. For some workflows, the default 'pgp' model may be overly strict:

Direct trust model (trust keys you've imported):

bash
# Per-command
gpg --trust-model direct --verify-commit HEAD

# Or set globally in ~/.gnupg/gpg.conf
echo "trust-model direct" >> ~/.gnupg/gpg.conf

Always trust model (for testing/CI only):

bash
# Trusts any imported key - NOT recommended for production
gpg --trust-model always --verify signature.sig file

Git-specific verification options:

bash
# Require valid signature but ignore trust
git config --global gpg.minTrustLevel never

# Require at least marginal trust
git config --global gpg.minTrustLevel marginal

# Require full trust
git config --global gpg.minTrustLevel fully

For CI pipelines:
The warning goes to stderr, but gpg returns exit code 0 for valid signatures. Your CI should check exit codes, not parse warning messages.

6Suppress the warning (if appropriate)

If you understand the warning and want to suppress it:

Option 1: Use trust-model in gpg.conf:

bash
# ~/.gnupg/gpg.conf
trust-model direct

Option 2: Mark the specific key as trusted:

bash
# Add to ~/.gnupg/gpg.conf
trusted-key <LONG_KEY_ID>

Option 3: Redirect stderr (scripting):

bash
# The warning goes to stderr, signature result to stdout
git verify-commit HEAD 2>/dev/null
echo $?  # 0 = valid signature

Option 4: For merge verification:
Git's --verify-signatures during merge looks for "G" (valid+trusted) status. To accept "U" (valid+untrusted):

bash
# Git 2.19+
git config merge.verifySignatures true
git config gpg.minTrustLevel never

Caution: Suppressing this warning removes a security check. Only do this if you have another way to verify signer identity.

Advanced notes

Understanding GPG Trust Levels:

GPG uses a web of trust model with these owner trust levels:
- Unknown (1): You don't know how carefully this person verifies keys
- Never (2): You don't trust this person to verify keys
- Marginal (3): You somewhat trust their key verification
- Full (4): You fully trust their key verification
- Ultimate (5): This is YOUR key (reserved for your own keys)

Trust is about identity verification, not data integrity. A "U" signature means the data is intact; you just can't prove who signed it.

Git Signature Status Codes:

When verifying signatures, Git reports:
- G: Good signature, valid key (trusted)
- U: Good signature, unknown validity (not in trust chain)
- B: Bad signature (data corrupted or wrong key)
- X: Good signature, expired key
- Y: Good signature, expired certification
- R: Good signature, revoked key
- E: Cannot check (missing key)
- N: No signature

The "U" status is what triggers this warning - cryptographically valid but not in your web of trust.

Why the Web of Trust Matters:

Anyone can create a GPG key claiming to be "Linus Torvalds." The web of trust ensures:
1. You only trust keys you've personally verified
2. Or keys verified by people you trust
3. This chain prevents impersonation attacks

Without the web of trust, an attacker could sign malicious commits with a fake key.

Verification Best Practices:

For open source projects:
1. Check if the key fingerprint is on the project's official website
2. Look for the key in official documentation
3. Verify the fingerprint matches what's published over HTTPS

For colleagues:
1. Verify fingerprints in person or via video call
2. Use your organization's key signing procedures
3. Consider using lsign for local-only trust

CI/CD Considerations:

In automated pipelines, you typically:
1. Import maintainers' keys non-interactively
2. Mark them as trusted using --import-ownertrust
3. Check exit codes rather than parsing output

Example CI setup:

bash
# Import and trust a key
gpg --import maintainer.key
FINGERPRINT=$(gpg --fingerprint maintainer@example.com | grep -A1 "pub" | tail -1 | tr -d ' ')
echo "${FINGERPRINT}:4:" | gpg --import-ownertrust

# Now verification won't warn
git verify-commit HEAD

Multi-Device Key Management:

When using the same GPG key on multiple machines:
1. Export your key: gpg --export-secret-keys -a > private.key
2. Import on new machine: gpg --import private.key
3. Set ultimate trust: gpg --edit-key <KEY_ID> then trust then 5

Your own key needs ultimate trust for the web of trust to work properly from that machine.

Keyserver Considerations:

Public keyservers allow anyone to upload keys, so never trust a key just because it's on a keyserver. Always verify fingerprints through independent channels. Some projects use dedicated key distribution:
- Linux kernel: https://www.kernel.org/signature.html
- Git: https://github.com/git/git/blob/master/Documentation/RelNotes/*.txt (signed tags)

Frequently asked questions

What does "gpg: WARNING: This key is not certified with a trusted signature! Ther" mean?
" warning indicates that while GPG can verify the signature is cryptographically valid (the data hasn't been tampered with), it cannot confirm that the key actually belongs to the person it claims to represent. This is a fundamental concept in GPG's web of trust model. Just having someone's public key in your keyring doesn't mean you trust their identity.
How do I fix "gpg: WARNING: This key is not certified with a trusted signature! Ther"?
This GPG warning appears when verifying signed Git commits or tags when the signing key is not in your web of trust. The signature is cryptographically valid, but GPG cannot confirm who owns the key. Fix this by signing the key or setting its trust level.
What causes "gpg: WARNING: This key is not certified with a trusted signature! Ther"?
The public key is imported but not signed or trusted by you (most common) No trust path exists between your GPG key and the signer's key You haven't set an owner trust level for the key
Is the "gpg: WARNING: This key is not certified with a trusted signature! Ther" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading