I am attempting to create a GCP Signed URL using instructions here. When I run the gsutil command to create my signed-url I am immediately prompted to enter my "Keystore password". So this:
gsutil signurl -d 10m my-private-key.json gs://my-storage-bucket/index.html
results in this:
Keystore password: [I enter a wrong password]
Encountered an error while refreshing access token. If you are using a service account,
please verify that the gs_service_key_file field in your config file(s), /Users/my-user/.boto, /Users/my-user/.config/gcloud/legacy_credentials/my-gcp-user-email/.boto, is correct.
To be frank I haven't the slightest what my keystore password is or even what keystore it is talking about. Is it a local Mac keystore? Is it a GCP keystore? Something else?
Any clues as to what keystore is being referenced or even how I might go about changing the password to something else are appreciated.
Here's what the signurl documentation says:
gsutil signurl [-c <content_type>] [-d <duration>] [-m <http_method>] \
[-p <password>] [-r <region>] keystore-file url...
[...]
gsutil signurl <private-key-file> gs://some-bucket/some-object/
The signurl command uses the private key for a service account (the
'' argument) to generate the cryptographic signature
for the generated URL. The private key file must be in PKCS12 or JSON
format. If the private key is encrypted the signed url command will
prompt for the passphrase used to protect the private key file
(default 'notasecret'). For more information regarding generating a
private key for use with the signurl command please see the
Authentication documentation.
So, the first argument after signurl, which in your question is my-private-key.json, is the keystore. It contains a private key.
Usually we encrypt private keys so that they are harder to steal. So when you created my-private-key.json, you were probably asked for a passphrase, and the passphrase was used to encrypt the private key.
But gsutil needs to decrypt the private key before it can use it to sign your URL. So gsutil needs the passphrase that was used to encrypt the private key. You need to enter that passphrase at the Keystore password: prompt. If you don't remember the passphrase you used to create the private key, then you will need to create a new private key.
(Perhaps the passphrase is in fact “notasecret”?)
Related
I am trying to get a better understanding of what is going on with gpg.
If you have a file and sign it: gpg --sign file.txt
you can verify it with: gpg --verify file.txt.gpg
when you get a successful output: gpg: Signature made...
But when you sign AND encrypt a file: gpg --encrypt --sign -r test#email.com file.txt
and then run --verify on the encrypted file I get: gpg: verify signatures failed: Unexpected error
I know that I can just call --decrypt on the file and it will verify and decrypt it, but what if I want to verify only?
I figured out the answer to this and then some. So I am going to add some additional information for clarity.
First of all, I realize based on the last line to this answer that gpg uses SIGN THEN ENCRYPT. Which means calling --verify or any variation to verify on an encrypted file will just output gpg: verify signatures failed: Unexpected error. This happens because the signature is "hidden" in encryption, so when you try to call --verify on the file, it will not see a signature.
Secondly, the --decrypt flag will both decrypt the file AND if the file is signed, verify it too.
Here is what --decrypt is doing. It looks at your default secret keyring secring.kbx in ~/.gnupg to use a secret key for decrypting the file. Then after it is decrypted, it looks at your default public keyring pubring.kbx in the folder ~/.gnupg and tries to verify the signature on the file, if it has one.
If it has no signature, it will just decrypt the file.
If it has a signature, but you don't have the public key, it will decrypt the file but it will fail to verify the signature.
If it has a signature and you have the public key, it will decrypt and verify.
With that said, there is no reason to verify a signed file BEFORE decrypting it.
Thirdly, as an added bonus, you can also specify a keyring you want to use for decrypting and verification. Say you want to use a temporary keyring to verify signatures or for what ever reason you want a temporary keyring to decrypt the message too.
You can specify the keyrings for --decrypt to use with the following command:
gpg --secret-keyring path/to/temp/secring.kbx --keyring path/to/temp/pubring.kbx --decrypt file.txt.gpg
This command will look for the secret ring and public ring at the specified paths in order to use those rings for decryption and verification instead of the default rings found in ~/.gnupg. Want to use a default ring with a temp ring? Just omit the flag and path to the ring you want defaulted.
All in all, for encrypted and signed files, if you want to decrypt and verify that file, you need to make sure that the private key for decryption is in your secret keyring and the public key for verification is in your public keyring.
One thing to understand about GPG encrypt & sign, which isn't very well explained, is that the signature can only be verified by the recipient.
Suppose Alice encrypts a file to send to Bob. She will encrypt with Bob's public key, and sign with her private key.
gpg --output encrypted.gpg --recipient B0B0000000000000000000000000000000000000 --armor --sign --default-key A11CE00000000000000000000000000000000000 --encrypt file-to-encrypt.txt
There's no way now for Alice, or anyone who does not have Bob's private key, to verify the signature.
Now Bob will decrypt the file. If it is signed, he'll see information about the signature in the output:
$ gpg --decrypt encrypted.gpg > decrypted.txt
gpg: encrypted with 2048-bit RSA key, ID D83A4C12B3840EBA, created 2020-09-24
"Alice <alice#example.com>"
gpg: Signature made 09/28/20 13:16:47 Eastern Daylight Time
gpg: using RSA key A11CE00000000000000000000000000000000000
gpg: Good signature from "Alice <alice#example.com>" [ultimate]
Note the Signature made and Good signature lines in the output.
$ gpg --encrypt --sign -r test#email.com file.txt
After file.txt.gpg generated, try the command below:
$ gpg -d file.txt.gpg
or just execute:
$ gpg file.txt.gpg
I have a aws ec2 inventory file that I want yo deploy my codes to the e2 instances. I am using:
anible-playbook -i ec2_inventory -u ec2-user --private-key=my_ec2_key.pem
and it works.
What I want is to use ansible-vault to encrypt the private key file: my_ec2_key.pem, and I will keep the vault password in a text file.
How can I issue the ansible-playbook command now to use the vault password to decrypt the private key file for ec2-user?
Unfortunately, ansible-vault will not automatically decrypt the private key that it's using to connect to instances. You could potentially hack around this by using a local task to write it into a keyfile from a variable file (which would write it decrypted) and place the file somewhere which is then referenced in downstream tasks. The reason ansible doesn't do this is because vault typically only decrypts the variables in-memory to prevent hanging decrypted artifacts if the playbook fails.
If you're using a CI box or something to run ansible, you could potentially place the private key on the CI box, and thus prevent the need to decrypt it at run-time. Then store the private key permanently encrypted in source.
I have generated 3 pairs of public and private keys using gpg. I would like to sign a file with one of this 3 public keys and then verify which of this 3 keys was used to sign the file.
How can I accomplish this?
I tried to sign the file with gpg --sign --default-key person1#gmail.com data.txt but do not know if its the right direction. Besides, what about veryfing?
gpg -d data.txt.gpg
Will decrypt the file (default -o is data.txt) and tell you which key signed it. If for some reason having a decrypted copy of the file on disk is a problem you might try
gpg -d -o /dev/null data.txt.gpg
It'll still tell you whether the signature was valid and what key signed it.
To specify which key to use when signing:
gpg --sign -u <key-id> somefile.txt
I am looking for help to figure out how to tie a secret key with a passphrase to encrypt a file using GPG.
I had tested many option (--encrypt, --sign, --recipient, --symmetric, etc), but in all of them, I was able to decrypt the file typing only the passphrase, even in a machine where I don't have the public nor the private/secret keys.
Is there a way to force the user to have the secret key and to be asked to type the passphrase?
I am open to any other idea that force a double security check to decrypt the protected file.
Thanks,
during decryption process type
gpg --allow-secret-key-import --import PrivateKey.gpg
after that prompt will appear for passphrase, enter the passphrase and after that decrypt file using
gpg filename.gpg
Dear ladies and sirs.
Observe this simple batch file:
makecert -n "CN=MyCA" -sr localmachine -ss root -a sha1 -cy authority -r -sv MyCA.pvk MyCA.cer
del MyCA.pvk
del MyCA.cer
makecert -n "CN=il-mark-lt" -sr localmachine -ss my -cy end -pe -sky exchange -a sha1 -is root -ir localmachine -in MyCA
However, the last makecert fails with the following error message:
Error: Fail to acquire a security provider from the issuer's certificate
How do I troubleshoot it? Any ideas? BTW, the first makecert succeeds. Of course, I delete it again, before running the commands again.
Thanks.
EDIT1
I understood the reasons for the failure. The second command expects the file MyCA.pvk to exist, but I do not want to keep it around. So, what can I do?
Just leave out the -sv MyCA.pvk part. It should still generate a private key and store it normally and not as a pvk file and it should be found by makecert ... -in MyCA.1
I was getting this error because I didn't start the command line with Admin privileges.
I guess the error is something of a misnomer in this case.
The problem is the first command, you are creating a self signed certificate and adding it to the Trusted Root store of the Local Machine account (but you probably know that). But you're also creating files for the public and private keys for the certificate, the .pvk and .cer files.
The second command is creating another certificate, this time not a self signed one but signed by the first certificate. In order to sign a certificate you need both the public and the private key of the issuer (CN=MyCA), you are instructing makecert to look for the issuer public key in the Local Machine Trusted Root Certificate store, that's fine, but you don't have the private key anymore, since MyCA.pvk was deleted.
If you don't specify file names for the private and public keys on the first command, i.e. do not include the -sv MyCA.pvk parameter and MyCA.cer, both the public and private keys will be added to the store. That means there will be no need to delete files because they won't be generated.
Also, if you open a management console, press [WIN]+[R] type mmc [Return], go to File -> Add/Remove Snap in -> Select "Certificates" -> "Add" -> "Computer Account" and then navigate the tree to Trusted Root Certificates\Certificates you will find MyCA in the left pane. You'll notice a small key on the icon and if you double click the certificate a message at the bottom of the General tab properties will state "You have a private key that corresponds to this certificate". That means you can use that certificate to sign a new one, like you're trying to do in with the second command.