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

GitINTERMEDIATELOW

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 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

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 [email protected]

# 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 [email protected] | 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)

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

What this error means

Typical symptoms

Common causes

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"

Advanced notes

Related errors

Official resources & further reading