Good morning Paul. Instead of having the mainframe run a process to call the script on the server, I was able to get an answer from 'them' regarding when the file would be available, and I've scheduled the process to run on the server. All is well now.
John Diaz 602-274-5359 x1284 jd...@azdes.gov -----Original Message----- From: Paul R. Ramer [mailto:free10...@gmail.com] Sent: Thursday, September 26, 2013 7:52 PM To: Diaz, John, A Cc: gnupg-users@gnupg.org Subject: Re: Decrypt Issue On 09/25/2013 09:36 AM, Diaz, John, A wrote: > Spoke too soon. The wrong path was part of the problem, but I’m still having > the issue: > > > Mainframe calls .bat file that calls C# application that calls second .bat > file to call GnuPG to decrypt a file. Once decrypted, other stuff happens, > e-mails are sent, blah, blah, blah. > > Here's the issue: When the mainframe calls the .bat file to start the > process, the decryption returns: > Decrypt error :gpg: armor header: Version: GnuPG v1.4.9 (AIX) > gpg: public key is 07F7097A > gpg: encrypted with ELG-E key, ID 07F7097A > gpg: decryption failed: secret key not available > > > > If I RDP into the server with the credentials specified in the mainframe JCL, > I see this from the decrypt: > > gpg: armor header: Version: GnuPG v1.4.9 (AIX) > > > > gpg: public key is 07F7097A > > gpg: using subkey 07F7097A instead of primary key AB96877A > > gpg: using subkey 07F7097A instead of primary key AB96877A > > gpg: encrypted with 2048-bit ELG key, ID 07F7097A, created 2007-05-25 > > "FMCSFTPKey <e-mail address>" > > gpg: AES256 encrypted data > > gpg: original file name='DE-ETE-090313' > > > > What do I need to do, or have the owners of the encrypted data do, to resolve > this? I do believe that your issue is caused by your script being run by your client system, and gpg is looking for the secret key on your *client* system. I think it is further indicative of this given that when you connect to server with Remote Desktop, it works. If the key is on the server and script is being run on the client, the reference to gpg in script will need to use gpg --homedir gnupg_directory_on_server. To test this, if you can edit the script that calls gpg, put a line in it to print out the value of the GNUPGHOME environment variable. Another way that you could do this is make gpg list its secret keys with gpg -v --list-secret-keys. By using -v option the first line of gpg's output will print the location of the secret keyring that is being listed. If it does not match the location of the secret key you have on your server, you have found your problem. If you do not have permission to edit the script, convince the responsible party to do himself. It is the only way you are going to know if gpg is looking in right place. When you get "secret key not available", your first recourse should be to determine if secret key you want is in your gnupg directory or if gpg is using the correct home directory. HTH. Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 ________________________________ NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
