When I run

gpg --verify ~/file.asc ~/file

I receive the following:

gpg: Signature made Tue 10 Dec 2016 05:10:10 AM EST using RSA key ID abcdefgh
gpg: Good signature from "Alias (signing key) <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: (a fingerprint)
     Subkey fingerprint: (a fingerprint)

The primary fingerprint matches the output of gpg --fingerprints In my keyring I have:

pub   4096R/abcdefgh 2014-12-12 [expires: 2020-08-02]
      Key fingerprint = (A public finger print)
uid                  Alias (signing key) <[email protected]>
sub   4096R/xcdertyu 2014-12-11 [expires: 2017-08-11]

I wanted to verify the authenticity of a file with the public key fingerprint. Note that the trust level is level 4 (full trust)

I believe this because:

:~$ gpg --edit-key abcdefgh
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  4096R/abcdefgh  created: 2014-12-12  expires: 2020-08-02  usage: C   
                     trust: full          validity: unknown

Should there be a reason for concern? Thanks for your patience as I learn more about crypto!

  • 3
    Google sent me here. My problem was unrelated, but my solution might still help other Googlers. In my case I had imported my own OpenPGP into Kleopatra on Windows, but still needed to mark it as my own (right click and select "Change Certification Trust...").
    – Jeroen
    Apr 11, 2018 at 7:53
  • The imported key (of the signer/signature) has not been validated by you or someone you trust, so the warning shows "not certified". The imported key needs to be --sign-key or --lsign-key by you (indicating your belief in that key) prior to --verify. See serverfault.com/a/1150984/278649 for more detail / instructions.
    – Baker
    Jan 6 at 4:54

2 Answers 2


The key needs to be verified. If you trust that someone's public key does in fact belong to that individual and they are in your keyring you can use your private key to sign your correspondent's public key and validate it.

So you are Bob and you trust that Alice's public key does in fact belong to Alice, so you sign it with your private key. So Alice's key is trusted to you. Also any keys that Alice trusts, say someone called Chris will be in your web of trust also. So you can also trust Chris, because Alice does. So Chris’s key will be certified with a trusted signature.

Now if Alice trusts that your key does belong to you then she can validate your public key with by signing it with her private key, therefore your key will now be included in that same web of trust.

a procedure was given to validate your correspondents' public keys: a correspondent's key is validated by personally checking his key's fingerprint and then signing his public key with your private key. By personally checking the fingerprint you can be sure that the key really does belong to him, and since you have signed they key, you can be sure to detect any tampering with it in the future. Unfortunately, this procedure is awkward when either you must validate a large number of keys or communicate with people whom you do not know personally.

GnuPG addresses this problem with a mechanism popularly known as the web of trust. In the web of trust model, responsibility for validating public keys is delegated to people you trust. For example, suppose

Alice has signed Blake's key, and

Blake has signed Chloe's key and Dharma's key.

If Alice trusts Blake to properly validate keys that he signs, then Alice can infer that Chloe's and Dharma's keys are valid without having to personally check them. She simply uses her validated copy of Blake's public key to check that Blake's signatures on Chloe's and Dharma's are good. In general, assuming that Alice fully trusts everybody to properly validate keys they sign, then any key signed by a valid key is also considered valid. The root is Alice's key, which is axiomatically assumed to be valid. Trust in a key's owner

In practice trust is subjective. For example, Blake's key is valid to Alice since she signed it, but she may not trust Blake to properly validate keys that he signs. In that case, she would not take Chloe's and Dharma's key as valid based on Blake's signatures alone. The web of trust model accounts for this by associating with each public key on your keyring an indication of how much you trust the key's owner.

There are four trust levels.


Nothing is known about the owner's judgement in key signing. Keys on your public keyring that you do not own initially have this trust level.


The owner is known to improperly sign other keys.


The owner understands the implications of key signing and properly validates keys before signing them.


The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.

A key's trust level is something that you alone assign to the key, and it is considered private information. It is not packaged with the key when it is exported; it is even stored separately from your keyrings in a separate database. The GnuPG key editor may be used to adjust your trust in a key's owner.

Read more here

Also have a look at this awnser from Server Fault

  • 2
    Can you explain the difference between 'trusting' and signing with my own cert? i.e. I manually verified the fingerprint and I edited/trusted, now why should I need to sign it also?
    – Rice
    Jan 6, 2017 at 19:44
  • I updated the answer to make it a bit easier to understand. Jan 7, 2017 at 13:31
  • Can I sign my own key, such that on my system it shows up as verified? Mar 21, 2019 at 22:26

I had this same problem. I think one possible solution is to update the trust store.

pub  4096R/abcdefgh  created: 2014-12-12  expires: 2020-08-02  usage: C   
                     trust: full          validity: unknown

Note the 'validity: unknown' - that is likely your problem.

Try command:

gpg --update-trustdb

(I am assuming you have already signed the key, either publicly, or locally with lsign)

ref for more details: https://unix.stackexchange.com/a/639518/138691

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .