I have just gone to https://couchdb.apache.org/ to get the latest CouchDB binary (upgrading from 2.2).
However, the download link redirects me to an organisation called Neighbourhoodie - a CouchDB services & consultancy firm (which was unexpected, but understandable as I know the installations may be served from mirrors).
When I ran the installer I got a warning from Windows that the binary is from an 'Unknown Publisher'.
I can't find a contact point on the CouchDB site to ask a question like this.
The unexpected redirect coupled with the Unknown Publisher have made me nervous - how can I know that it's safe to proceed with the upgrade?
You can verify that the couchdb contributors that signs public releases believed this binary is correct for windows users by comparing the site, sha1 and md5 sums they gave in an issue. Neither a sha1 or md5 alone is secure, but I think it would be exceedingly hard to find an attack that simultaneously works for both.
Also, if you download the gpg signature, binary and the https://downloads.apache.org/couchdb/KEYS you can verify that this signer is the same signer using the same key recognized on the apache download site. Using their trust is similar to tofu, you trust the channel with https and it trusts this key, so now you trust the key on another channel.
On linux/mac this looks like:
(verify you obtain keys over ssl from apache, then:)
$ gpg --import KEYS.txt
...
gpg: key CDE711289384AE37: "**** (CODE SIGNING KEY) <****#apache.org>"
(download a sig and file from official downloads.apache.org site and verify + add your "tofu" trust in this key)
$ gpg --trusted-key CDE711289384AE37 --verify apache-couchdb-3.1.1.tar.gz.asc
(your gpg now trusts this key for new binaries)
$ gpg --verify apache-couchdb-3.1.0.msi.asc
(If the official KEYS file changes you would want to delete this trust and do the same process again:)
$ gpg --delete-key CDE711289384AE37
and windows gpg should look similar, maybe with / in place of --, etc.
Related
I have an ETL that is Un-PGPing a file sent to us. This process works for two people on our team but fails for the rest on the unPGP step. We all use Kleopatra for our key encryption/decryption and have the same key's imported.
I have noticed that the keys on the systems that work are set to the trust level "This is my certificate" (sometimes called Ultimate trust). However the option to set to that level on the other systems are grayed out.
I have tried to change the level via a CMD prompt based on this article:
https://security.stackexchange.com/questions/129474/how-to-raise-a-key-to-ultimate-trust-on-another-machine
However I do not get the same prompts as described.
When debuging with CMD /K I see:
gpg: decryption failed: No secret key
UNPGP Failure Message
I found out how to change my trust,
gpg --edit-key [key-id]
trust
5
though this didn't end up solving my problems.
I discovered when I typed gpg --list-secret-keys I would get nothing in return despite having kleopatra tell me the keys were properly installed.
I found and staged the secret key's I needed then imported them using GPG.
gpg --allow-secret-key-import --import "filename.asc"
This fixed my issue!
I'm adding automatic upgrades to an application of mine. I need code-signing for this, or else automatic upgrades could be an attack vector. I need the signing and verification to be doable with "openssl" commands, since my application can run on any platform, and OpenSSL is available on any platform. However, when I try to verify a timestamp with openssl, with the code-signing certificate I bought from Comodo, I get the error "Verify error:unable to get local issuer certificate". The commands I run are as follows:
First, I extract the private key and the certificates from the .p12 file from Comodo, with the following:
openssl pkcs12 -in full-certs-from-comodo.p12 -nocerts -out private-key.pem
openssl pkcs12 -in full-certs-from-comodo.p12 -nokeys -out certs.pem
Then, to query and verify a timestamp, I run:
openssl ts -query -data mydata.tar.gz -cert -CAfile certs.pem -sha256 -out request-256.tsq
cat request-256.tsq | curl -s -S --data-binary #- -H 'Content-Type: application/timestamp-query' 'http://timestamp.comodoca.com?td=sha256' > response-256.tsr
openssl ts -verify -sha256 -in response-256.tsr -data mydata.tar.gz -CAfile certs.pem
This is the full error that results:
Verification: FAILED
140710242829968:error:2F06D064:time stamp routines:TS_VERIFY_CERT:certificate verify error:ts_rsp_verify.c:246:Verify error:unable to get local issuer certificate
Comodo tech support can't solve it, and I've been communicating with them for a month now. Digicert says they can only sign certain kinds of files, and those don't include a .tar.gz file. *sigh*
I've never used code-signing before, but that doesn't sound right to me, unless Digicert is adding artificial restrictions. Can't I hash any file, sign the hash with a private key, and then verify it on the user end with the public key? I don't think it should be this hard. What don't I understand?
Anyway, I'd love to get this working even with a paid certificate vendor, but failing that I'm wondering if I can just create my own key pair (a la PGP) and use that. I guess I wouldn't be able to revoke the certificate; are there any other downsides? In particular, does anyone see any reduced security by doing it this way? I do need very good security for this app.
The application is a Perl script and normally runs on a Web server, i.e. usually a *nix platform, but can also run on Windows.
Thanks! I appreciate any clues in getting this working at all, in any way, paid or not. I can't be the first person to need this kind of code-signing, but Comodo and Digicert tech support seemingly haven't heard of it at all.
Maybe not an answer but definitely too much for comments.
Aside: OpenSSL is available on many platforms, but not all. Although you only care about platforms where your app can be installed, and perl is already pretty demanding of platforms and can't be installed anywhere near everywhere.
More Important: code-signing and trusted timestamping are different and separate things, although sometimes used together: some codesigning schemes like Microsoft and Java encourage (but don't require) you to get a trusted timestamp on the (code) signature; I'm not sure about Apple, or Android. In particular you can't (validly) use a code-signing cert for timestamping, or verifying timestamps, and if you can get a timestamping cert (you probably can't meet the requirements to be trusted by anyone besides yourself, see below) you can't use it for signing or verifying code. Although the error you got on ts is probably not because of this misuse but because you did something else wrong, but you don't tell us what you did, and imagining and describing the very many things you could possibly have done wrong would take far more than is justified for or even fits in a single Stack answer.
The cert can't restrict what you can sign, but it may restrict where that signature will be trusted. In particular for Microsoft Authenticode, only a cert from a CA specifically approved by Microsoft will work. And I believe Apple only trusts certs they themselves issue.
Yes, if you control both/all ends you don't need a 'real' cert; the (only) value of a trusted-thirdparty CA, and certs from it, is allowing your system(s) and/or code to trust data or code from those of other people, and/or other people's to trust yours, under known and more or less reasonable conditions. You presumably trust yourself entirely, unless you're Michael Garibaldi. If you use OpenSSL's 'primitive' signing functions (commandline dgst -sign/verify or rsautl/pkeyutl -sign/verify, or the equivalent library calls) you only need the two keys, private and public. If you use CMS (aka PKCS7) or S/MIME signatures you need a cert, but it can be a self-signed cert with any identity information, true or false, you feel like putting in it.
I've done a fair bit of reading about digital signatures but I can't for the life of me work out why I'd need to verify the signature of a digitally signed file uploaded on a mirror site.
The question popped up when I tried to install Maven:
https://maven.apache.org/download.cgi
The site urges you to "verify the signature of the release bundles against the public KEYS used by the Apache Maven developers".
I understand the need for integrity which a checksum provides (granted MD5 is considered weak) - why do I need to do more? I know the file that I've downloaded has not been modified since the checksum was initially generated.
Digital signatures are supposed to provide integrity, authenticity and non-repudiation.
1) Integrity is already provided anyway by confirming the checksum.
2) Authenticity - verifies identity of signer. In this case, the signer is the owner of the public key (supposedly a maven developer). In this scenario, do I really care who signed the file?
3) Non-repudiation - Do I really care that the developer can't deny the file was signed by him/her? Maybe if the maven developer created a malicious file and I wanted to sue them for distributing it...
I don't see the significance of authenticity here. I KNOW the sender (eg. someMirrorSite.com) is not the one who signed the file since if I use their public key to try verify the signature, it would be invalid. If I use the maven developer's public key all I'm verifying is the fact that the maven developer signed the file (granted they have a valid certificate which links that maven developer with their public key).
So basically the question is: Provided that I trust maven.apache.org, why should I verify the signature of the file hosted by the mirror site when I can just simply verify the checksum of the file?
Is basically a perspective, do I care who made or compiled a file? Who is behind this so called signed document/file/byte array?
Behind a signed file is Private Key Infrastructure, is like having a notarized document when a particular risky transaction is on play and a bunch of lawyers around, why should I care? Well it depends how important that activity is for you or a third party. Let's say You want to sell a company (small business). This is risky, may be not for you but for the third party, he will make sure there is a notary present to witness the transaction and the state he is receiving the company. At this point it becomes clear to you that you also need a notarized document of you selling the company. Who knows what's going to happen next? May be you don't care what happns next, as long as it's sold, so no notarized document (aka digitally signed document).
Check Integrity = Just lawyers
Digitally Signed Document = You don't trust lawyers that much so you need a notary (who is basically a lawyer anyway :-))
If there is a file F, and C = checksum(F), then when you download F you can recompute C and see if it matches the published value. But, how do you know if this published value of C can be trusted? If I am "Evil Inc." I can make a compromised copy of F, call it Fe and then compute its checksum Ce, and publish both on my website. Many people will not bother to even look at the checksum, but even those that do will be fooled, because they will compute Ce too.
Using a Public Key signature as the checksum is an attempt to strengthen this procedure.
I would like to be able to determine if a remote domain's TLS/SSL certificate is 'trusted' from the command line.
Here is an openssl example I was playing with a few weeks back, here I use openssl to acquire the certificate and then pipe it to openssl's 'verify' command. I assumed that the 'verify' command would verify the certificate, however, how I understand it now is that the 'verify' command just verifies the certificate chain (I think). (cdn.pubnub.com is just a domain I found from a quick Twitter search as an example to use)
echo "GET /" | openssl s_client -connect cdn.pubnub.com:443 | openssl x509 -text | openssl verify
As you can see from the cdn.pubnub.com domain (at the time of writing), the browser (Chrome at least) does not trust the certificate (because the certificate domain doesn't match), however, the openssl 'verify' command does not output 'trusted' or 'not trusted' or something else we can deduct that information from.
Another way I thought of doing this, is by using a headless browser (such as PhantomJS) and parsing any errors they return. It turns out that PhantomJS just errors but does not give any details, so this can not be used as the error could have been caused by something else.
I didn't think it would be this hard to find out that a certificate was trusted or not from the command line, without having to parse and check all the data that makes a certificate trusted myself which I don't think would be wise.
Is there a library or some other way I can tell if a remote domain's certificate is trusted from the command line?
curl (and libcurl) uses OpenSSL for https URLs, and checks certificate validity unless -k, --insecure option is enabled.
zsh 29354 % curl https://cdn.pubnub.com/
curl: (51) SSL peer certificate or SSH remote key was not OK
As you see, it doesn't give much details on why the certificate is invalid, but otherwise it should be as good as a headless browser, and much lighter.
It depends on what you consider "trusted". Beside the core cryptographic checks (e.g. checking the digital signature) the client usually does the following:
Check that the certificate chains to a trusted root
Verify that the current time is between the notValidBefore and not validAfter attributes.
The certificate is not revoked.
keyUsage and other certificate constraints match.
The entity we are communicating is somehow found in the subject of the certificate (for servers this usually means the hostname is listed as CN or subjectAlternativeName).
In your case the information to verify step 5 (namely the hostname) is missing, so it cannot be checked. You would have to do this step yourself.
Please note that different clients perform different checks to see if a certificate is trusted, so one answer may not apply to all possible clients. If you want to check your installation deeply, consider using the check from ssl labs https://www.ssllabs.com/ssltest /
Fatal error: Uncaught CurlException: 60: Peer certificate cannot be authenticated with known CA certificates thrown in /home/ldr/public_html/src/base_facebook.php on line 886
See: http://ldr.x10.bz/examples/with_js_sdk.php
I've been getting this error for 2 days now and can't find any information on where it has come from? Why is the certificate known and is there a way for it to be unknown again?
It had been working for months previously, so not sure if the API has just updated but I've deleted everything and just uploaded the PHP SDK 3.1.1 but still no luck :(
I've read about disabling the peer verification but sounds like a bad idea (plus I know it works with it enabled). Probably accidentally unchecked a box somewhere- any ideas on how to restore it back to normal would be very appreciated :)
Thanks!
Certificates are verified against a truststore somewhere on your system. This truststore should be updated once in a while; e.g. Firefox and Windows do this when updating the software. The error is a bit unclear; it actually means your curl client gets a certificate for which it does not have a trusted (root) certificate.
You may want to visit that site with your favorite up to date browser and save the root certificate somewhere, then create a CA store with that single certificate in it. Of course it will fail if that one gets replaced or if the server chooses another certificate authority.
Possibly updating curl or the OpenSSL library may do the trick, try that first :).