Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to validate the integrity of my httpd-2.2.17.tar.gz image.
I followed the steps written in the following pages:

But I got:

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

What I need to do in order to verify the authenticity of the key?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

The usual means of verification is to contact the key owner and ask him/her to provide you (over the phone, or in person) with their key fingerprint. If you have strong reason to believe you are actually speaking to the person identified by the key, AND if the fingerprint the person provides matches the fingerprint of the key you have, THEN you can be quite certain you have the owner's real public key (and NOT a counterfeit key, created by an imposter for the purpose of impersonating that person).

Once you have verified the authenticity of the key to your satisfaction, you should sign that public key with your own private key. Once you've signed the key, you will no longer get those WARNINGs, because by signing it, you have indicated that you believe the key to be authentic.

share|improve this answer
I should add: Often, it is difficult or impossible to strongly verify that a key is legitimate, especially when it is a key provided for package verification purposes as described here. In this case, you may have to simply use your best judgement as to whether you trust the key's authenticity. –  Steven Monday Nov 14 '10 at 22:21
Thank you for your nice & clear explanation. +1. So the GPG method of verifying the integrity of a file is kinda useless, isn't it? I think I should better use SHA1. –  Dor Nov 15 '10 at 18:25
For a one-off verification, yeah pretty much. You're either trusting a PGP/GPG key to be authentic, or a SHA sum file to be authentic. However, if you're following a project over many years and many releases, if the legitimate releases have been consistently signed by the same key, then I would tend to trust that the key is probably real. –  Steven Monday Nov 15 '10 at 19:02
I couldn't understand though why do I need to validate the authenticity of a key, if I download it from Apache's server? I download the file/image to be verified from a mirror, but the keys and file/image signature are downloaded from Apache's server. I will do the same thing for SHA1 verification, without the requirement to verify the SHA1 hash or something like that... –  Dor Nov 15 '10 at 20:26
The procedure described in my answer is the canonical means of verification, but it is not the only one. If you completely trust the source where you obtained your copy of the key, then you may decide to trust the key without verifying the fingerprint. (In fact, most people probably don't bother to verify a key so rigorously.) Ultimately, it is completely up to you to decide whether you feel the key is authentic. As I said, if you're only using it for a one-off verification, then there is no benefit using the key over a published SHA1 hash. –  Steven Monday Nov 15 '10 at 20:57
show 1 more comment

There are two distinct purposes for file verification:

  1. A. to protect against accidental corruption during downloading

  2. to protect against a MITM-attack, or even webserver compromise if the private pgp key has not been compromised.

For A, a hashing function like SHA-1, MD5, ... is more than satisfactory. However it would do no harm to use a more modern hash that is still considered cryptographic.

For B, things get seriously more complicated. For starters you should be doing all communications by correctly certified HTTPS (SSL):


You're in luck, apache does provide such access to their website.

Now lets make an assessment of what risks remain and what risks have been mitigated. A simple MITM-attack is no longer possible. To still execute a MITM-attack an attacker could however:

  1. Obtain a certificate for this website from a Certificate Authority by:

    • tricking them into believing that they own this website and paying them.
    • tricking browsers in accepting them as a CA (note that several governments are included in browsers as CA, and that existing CA's can delegate the trust they receive to third parties without any notification, see the etisalat incident) If this then comes to light that this subCA does some bad shit, and the CA refuses to revoke this subCA then there is still all the websites that are legitimately certified by the CA, which causes a pressure on browsers to keep trusting the CA.
    • by breaking in and stealing the private key of the CA
    • by forcing them by law to make such a certificate (subpoena)
  2. Steal the private key of the server sending the data.

Wow, that might not be perfect, but imagine having to do something like that. I bet your geek baby brother upstairs doesn't often come round to that. It considerably raises the bar for an attacker.

Further, if an attacker could just compromise the server of the website, they could just change the file as well as the md5, sha1 or other hashes as well as the pgp keys it serves, and therefore wouldn't have to do a MITM-attack. This last option is by far the preferred as it is often simpler to get into a server than to get a certificate.

Note that sometimes the hashes and downloaded files are not served from the same location. In itself that is good. It would complicate the work of an attacker. So, say I have a https certified website and you offer some files for download. I might offer to put the hashes of those files on my website to help you out. Or in case of apache, the actual downloads are on mirrors which do not have https.

Now the hashes are the crucial link in the verification. Note that MD5 has been broken and that SHA1 is on its way. It is bad from apache to still provide these for security purposes. If all else fails and both of them are available, check them both. A collision attack to yield both the same md5 and sha1 values for two file has not yet been discovered as far as I know.

What if https is not available for the given site. Well, a file served to you from that server is just as safe as a hash on the website (if it is on the same server), or a pgp key, or anything else for that matter.

Beyond https:

If https does not satisfy your need for security (and really it shouldn't) or https was not available for the website, what can you do?

Using a pgp key to verify signatures might allow you to verify the files if you can get a legitimate public key from the signer. PGP uses a system called Web of Trust in order to verify its keys, as opposed to the central Certificate Authorities used in HTTPS.

When you include a pgp key in your keyring it is not necessarily known if this key really belongs to the user id that comes with it. To be able to verify that, users sign each others keys after verifying each other's identity, for example by meeting in person or calling that person. Further it is possible to construct a chain between you and say the apache signing key if you haven't verified them in person but someone you met did, or they met someone who did...

Thus, when a new key enters your keyring, and none of the other keys in your keyring that are already verified have signed this key and you try to use it, gpg or pgp will issue a warning, just like browsers give you a warning if you surf to an https website who's certificate can not be verified.

Apart from signing the key yourself to verify that it is legitimate the software might automatically accept it as valid if one of your fully trusted contacts signed it, or 3 marginally trusted contacts signed it... That is implementation/user dependant. Just as your browser will silently accept any SSL certificate if it is signed by a CA that is known to be trusted (by your browser that is).

What does this all mean in practice? Well, if you are in the middle of the geek-knows-geek world, this probably gives you a reasonable protection. For the rest of the world, it is more like a monstertruck without petrol.

For ordinary people pgp and the web of trust have some considerable problems:

  • improper use of gpg and web of trust breaks its security
  • proper use of it is difficult, complicated and free tools like gnupg and it's frontends are shaggy
  • if you or the other side are not well anchored in the web of trust, verifying keys is next to impossible
  • a chain of trust really means you have to trust all the people in between. The longer it gets the less safe. If say all your links to the apache signing key pass through the same persons that might set up a MITM-attack, than pgp only serves as a false sense of security.
  • Web of Trust helps authorities to draw a map of your social network just like facebook.

It does however not suffer from some of the limitations of https, like it is not possible with pgp to convince one company to take your money and give you a certificate that will fool the entire world. On the other hand, it is considerably less usable for the general public. It illustrates how simplicity is a key determinant for security.

In conclusion it is important to realize that HTTPS and PGP are not mutually exclusive. No one prevents you from trying to use both to the best of your ability. What one should realize is that any chains of security are only as strong as the weakest link. Say a pgp key downloaded through https has the weaknesses of pgp and the weaknesses of https. Every link in a chain adds its weaknesses to the result.

I will keep adding interesting links to this answer as I discover them.

See also:

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.