This is a weird one. A customer is using my public key to encrypt a file and send it to us via SFTP. The file is also password protected. Previously, this worked without error until we migrated to a new server. We copied the keyring from the old server to the new server, installed GPG and after a reboot, every other decryption was working except for one. Several other files also use our public key.
Our automated process keeps failing the decrypt step, but when I manually decrypt, the file decrypts with the “Can’t check signature: No public key” error.
Again, this is our public / private key pair being used. I’ve verified that the file is indeed using the subkey of our public key. The DSA ID isn’t the same as the properties on our certificate, though, so I’m not sure if this is the issue. I’ve tried numerous times to re-import our .asc key file but I get “total processed 1” and “unchanged 1” as the response. I’ve gone into Kleopatra and the file is there.
I don’t understand why all the files but this one works without issue and why this file decrypts but keeps saying I don’t have my own public key.
there are several potential causes for the observation you are making.
Did you change the Gpg4win version between the old and the new server?
If so, from which to which? (Background: Newer versions sometimes treat elder
algorithms differently for security reasons.)
Obviously something must be different between the old and the new setup,
the question is what, and which of these differences affect the situation.
The “Can’t check signature: No public key” refers to the public key of the signatur, thus of the sender. Try to list this public key and try if you encrypt to this public key manually.
If you cannot, using the command line with -v can give you the reason for the problem.
This message may change the error code on the decryption, so even if you could decrypt
the script may see the problem from verifying the signature and aborts. Depens on the
error handling. Note that this probably the correct behaviour as the signature is important
to verify where the file came from. Otherwise everybody could insert files in that process
Another thing you can try is do to a manual decryption with higher diagnostics
(-vv --debug-all) and see more precisely what maybe the difference with how the file
I tried the -v before I posted here and got the below messages. The only thing off I saw was the DSA key ID in the error message did not match the DSA ID I saw in the cert properties of Kleopatra. But the subkey and primary key matches my public key that they are using to encrypt.
gpg: public key is ABCDEFG
gpg: using subkey ABCDEFG instead of primary key 1234567
gpg: using subkey ABCDEFG instead of primary key 1234567
gpg: encrypted with 2048-bit ELG key, ID 2222222, created 2009-08-05 <name of Cat’s cert here>
gpg: CAST5 encrypted data
gpg: original file name=‘file.txt’
gpg: Signature made 03/29/22 01:19:42 Central Daylight time use DSA key ID XXXXXXX
gpg: Can’t check signature: No public key
gpg: WARNING: message was not integrity protected
I ran it again using -vv --debug-all and I’m not seeing anything that stands out to me in the log. Just, near the end of it, the same information as I posted above. I’m not sure how much of the log I can post safely without risking our security, If I scrub file names and paths, and remove the decrypt section, will I be able to post without compromising anything?
can you import DSA key ID XXXXXXX, that is the one that is missing to verify the signature?
If you do not have it, request it from your partner as he/she should be in control of the private key part to that public key.
gpg -v -k XXXXXXX
gpg -v --encrypt -r XXXXXXX somefile.txt
and see what it says. This tests if you have XXXXXXX and if it is ready to be used.
If I scrub file names and paths, and remove the decrypt section, will I be able to post without compromising anything?
In theory yes: if you remove file names, path and ids… but it should not be necessary. See my other response.
I don’t know how I can make this any clearer. It is MY private key. They are using my public key to encrypt the file and send it.
So, regarding the DSA key ID, I just use the --import and just enter the DSA key ID number that error message says is being used? I’m a little confused by this part.
So I can’t edit messages, but I just reread your comment about the DSA key and amend my previous response from --import to -v -k.
I’ll try it and see what happens.
So the -v -k doesn’t do anything but give me information I already know. The version of GPG is the same between old server and new server. The keyring has the same exact keys between the two.
The only odd thing I’ve noticed is that on the old server it was popping the same error but it didn’t disrupt the automated process.
I’m using a SQL Server SSIS package with a VB script task for decryption. On SQL Server 2019 / Windows Server 2012 R2, the package works fine and the file gets decrypted despite the error. On SQL 2019 / Windows Server 2019, the error causes the package to log the file as failed. No matter what I do, I can’t get the package to pop back the error to prove it’s exactly the same one as what I’m seeing in a command prompt.
Still not sure why the old one worked and the new one won’t. This is driving me nuts.
as there must be a difference and you’ve checked the GnuPG versions and the keyring,
the difference must be somewhere else.
Maybe the scripting environment reacts differently to the error in the two versions.
If you technically know how, you could try to write a small application that gives the same status codes than the old GnuPG process and then see if you get a different behaviour with it, when running it instead of GnuPG. Then you would have proven that it is not GnuPG.
After pulling teeth from the customer, I finally figured out the issue. The customer used our public key to encrypt the file, but signed the file with their private key.
After searching the gpg documentation, the only thing I can find on multiple keys is the command for encryption. I can’t find any command that will tell me how to check a public key for a signature and decrypt using my private key at the same time.
Does anyone have any advice for that?
If you use the command “gpg --decrypt” it does both: Decrypt a file and verify the signature.
Is that what you are looking for?
Unfortunately it’s not working. As I said in my original post, the file decrypts but the signature cannot be verified because there is no public key.
The customer’s public key is loaded into my key ring. That’s what the signature is against. The encryption is against my public key.
That’s why I’m trying to figure out how to decrypt with my private key and verify signature against their public key.
as Christoph wrote: `gpg–decrypt’ does both decryption and verification.
And as I understood from your previous writings, the version on server A you have, works fine with it. And server B does not.
The question remains: Where is the difference between A and B.
a) On A you have imported the public key (pubkey) of your customer and you have signed it (which indicates that you know that this is the right pubkey of your customer. And on B you either have not imported the pubkey or you haven’t signed it.
gpg --list-key customer-name
on A and B. It both should show the same pubkey with “full” being displayed.
b) A and B have the same pubkey, but both did not sign them and the scripting environement changed its behaviour regarding the return value of the decryption and verification process. B treats the returin value of a failed signature validation differently than A. (Though both get the same return value.).
To check (see my last post.)
gpg --list-key customer-name fails with “gpg: error reading key: no public key”.
I do have the public key they sent me in the key ring. I’ve verified it several times. That leads me to the conclusion that maybe they sent me the wrong public key. I’ve asked their tech support to help with this.
Further testing with the old server indicates that this problem also existed there but it was not failing completely. It would just pop the “no public key” error, continue to decrypt and pushed the file along the process. So I think that it might be a difference between Windows Server 2012 R2 security and Windows Server 2019 security. Or something along those lines. Basically better security is refusing to allow this failure to be ignored.
I do appreciate everyone’s help. Thank you.
Well “customer-name” must be a part of the uid that is on the pubkey. If can do a gpg --list-keys to list all keys in your public keyring. Maybe you have the wrong keyring or the old keyring format with a new GnuPG.
FINALLY. The customer sent me the correct public key. I loaded it and was still getting the error, then discovered I had to sign their public key with my private key (–edit) and then change the trust level to FULL.
But then I got a comment about changes wouldn’t be reflected until gpg was restarted. That’s my new battle and I’ve posted a new thread.
Thank you Bernhard and Christoph for your assistance!
As far as I know it is not necessary that you have to do anything (if that’s not so Bernhard will correct me I hope ).
I just tested the following:
*I opened a signed message (whose key had ultimate trust) in Claws Mail which displayed that the key has ultimate trust
*Then I used --edit-key and set the trust of the same key to fully. I didn’t even enter quit but directly went to Claws Mail and checked the signature. It showed that I fully trust the key.
For me this seems like there is no additional action necessary.
This is the message I got:
gpg Please note that the shown key validity is not necessarily correct unless you restart the program.
And the file failed again this morning after I signed and trusted the key, so I’m hoping a restart will have it running smoothly.