According to the manual of ssh-keygen
, -k flag generates some KRL file. What do these KRL files mean and how I specify a KRL location while using this flag?
According to FreeBSD Manual Pages BSD General Commands Manual :
KEY REVOCATION LISTS
ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
These binary files specify keys or certificates to be revoked using a
compact format, taking as little as one bit per certificate if they are
being revoked by serial number.
KRLs may be generated using the -k flag. This option reads one or more
files from the command line and generates a new KRL. The files may ei-
ther contain a KRL specification (see below) or public keys, listed one
per line. Plain public keys are revoked by listing their hash or con-
tents in the KRL and certificates revoked by serial number or key ID (if
the serial is zero or not available).
Revoking keys using a KRL specification offers explicit control over the
types of record used to revoke keys and may be used to directly revoke
certificates by serial number or key ID without having the complete orig-
inal certificate on hand. A KRL specification consists of lines contain-
ing one of the following directives followed by a colon and some direc-
tive-specific information.
serial: serial_number[-serial_number]
Revokes a certificate with the specified serial number. Serial
numbers are 64-bit values, not including zero and may be ex-
pressed in decimal, hex or octal. If two serial numbers are
specified separated by a hyphen, then the range of serial numbers
including and between each is revoked. The CA key must have been
specified on the ssh-keygen command line using the -s option.
id: key_id
Revokes a certificate with the specified key ID string. The CA
key must have been specified on the ssh-keygen command line using
the -s option.
key: public_key
Revokes the specified key. If a certificate is listed, then it
is revoked as a plain public key.
sha1: public_key
Revokes the specified key by its SHA1 hash.
KRLs may be updated using the -u flag in addition to -k. When this op-
tion is specified, keys listed via the command line are merged into the
KRL, adding to those already there.
It is also possible, given a KRL, to test whether it revokes a particular
key (or keys). The -Q flag will query an existing KRL, testing each key
specified on the command line. If any key listed on the command line has
been revoked (or an error encountered) then ssh-keygen will exit with a
non-zero exit status. A zero exit status will only be returned if no key
was revoked.
Related
I'm performing a call of this CLI function
spl-token balance --token--
So it requires a keypair.json file to be present at this location ~ .config/solana/id.json (for Mac)
Without this file CLI throws an error
error: No such file or directory (os error 2)
Is there a way to specify a path to keypair or even better specify the whole file content (encoded or not) as a CLI param?
BTW this issue is not limited to just this command, most of spl-token cli commands I've tried has this issue.
If you want to specify the keypair directly, you can use the --fee-payer argument, ie:
$ spl-token --fee-payer id.json balance --owner <YOUR_PUBKEY> <TOKEN_MINT_PUBKEY>
The --fee-payer argument accepts a few different possibilities, including keypair files, or even keywords that accept input from stdin. More information at https://docs.solana.com/wallet-guide/paper-wallet#hierarchical-derivation
It isn't super intuitive, but the possibility is there. For example, a balance check shouldn't need a signer. PRs / suggestions for improvement are always accepted on GitHub! https://github.com/solana-labs/solana-program-library
This has always been possible with the prompt:// argument, which enabled paper wallets. For USDC:
spl-token transfer EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v <AMOUNT> <RECIPIENT_ADDRESS> --fund-recipient --allow-unfunded-recipient --owner prompt:// --fee-payer prompt://
You'll then be able to paste the private keys of the owner and the fee payer.
I created a pair of *.pub and *.sec files using the instructions and code given here:
https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html
(I am using this documentation because the ultimate application I have in
mind is an automated encryption/decryption pipeline.)
Q1: How can I use gpg2 and the *.pub file to encrypt another file?
Q2: How can I use gpg2 and the companion *.sec to decrypt a file encrypted using the companion *.pub file?
Important: I am interested only in answers that are suitable for programmatic implementation of an unsupervised operation. Please do not post answers that can only be carried out interactively. I am particularly interested in solutions that can be implemented in Python.
Please include precise pointers to the relevant documentation.
Some information about what you said:
I created a pair of *.pub and *.sec files using the instructions
Perfect to share the public key(s) with people you are exchanging information, but technically, when you are working programmatically, you don't need to use these files directly.
To be noted:
when you encrypt data, you will specify the recipient corresponding to the key to use to encrypt
when you decrypt data, you will first import the owner's public key, and then you will be able to decrypt data without specifying recipient, because it is embedded in the encrypted data
Actually, I am somewhat confused on this question. I have read conflicting information [...]
I agree it's quite confusing. In this situation, I think it is better to use version 1 for which there is more experience, and for which you find third party library to use.
In this answer, I tried:
python-gnupg (for GnuPG v1) which is a well known Python library and match perfectly your needs
cryptorito (for GnuPG v2) for which I didn't find enough documentation
With the first library, you can simply install it in your system:
sudo pip install python-gnupg
And then write a Python script to perform all the operations you want.
I wrote a simple one to answer your question.
#!/bin/python
import gnupg
GPG_DIR='/home/bsquare/.gnupg'
FILE_TO_ENCRYPT='/tmp/myFileToEncrypt'
ENCRYPTED_FILE='/tmp/encryptedFile'
DECRYPTED_FILE='/tmp/decryptedFile'
SENDER_USER='Bsquare'
TARGET_USER='Kjo'
gpg = gnupg.GPG(gnupghome=GPG_DIR)
print("Listing keys ...")
print(gpg.list_keys())
# On SENDER_USER side ... encrypt the file for TARGET_USER, with his public key (would match the kjo.pub if the key was exported).
print("Encrypting file " + FILE_TO_ENCRYPT + " for " + TARGET_USER + " ...")
with open(FILE_TO_ENCRYPT, "rb") as sourceFile:
encrypted_ascii_data = gpg.encrypt_file(sourceFile, TARGET_USER)
# print(encrypted_ascii_data)
with open(ENCRYPTED_FILE, "w+") as targetFile:
print("encrypted_ascii_data", targetFile)
# On TARGET_USER side ... decrypt the file with his private key (would match the kjo.sec if the key was exported).
print("Decrypting file " + ENCRYPTED_FILE + " for " + TARGET_USER + " ...")
with open(ENCRYPTED_FILE, "rb") as sourceFile:
decrypted_ascii_data = gpg.decrypt_file(sourceFile)
# print(decrypted_ascii_data)
with open(DECRYPTED_FILE, "w+") as targetFile:
print(decrypted_ascii_data, targetFile)
To be noted my keyring contains pub/sec pair for my Bsquare user, and the pub key of Kjo user.
when looking at encrypting and decrypting documents
this hints for pexpect; while I can provide regular expect scripts:
this is not directly a Python solution, but it should be easy to port.
as the tagline reads:
Pexpect makes Python a better tool for controlling other applications.
Encryption:
gpg --output doc.gpg --encrypt --recipient blake#cyb.org doc
as expect script; usage ./encrypt.exp doc blake#cyb.org 1234 (notice the space after the :):
#!/usr/bin/expect -f
set filename [lindex $argv 0]
set recipient [lindex $argv 1]
set passphrase [lindex $argv 2]
spawn gpg --output $filename.gpg --encrypt --recipient $recipient $filename
expect -exact "Enter pass phrase: "
send -- "$passphrase\r"
expect eof
Decryption:
gpg --output doc --decrypt doc.gpg
as expect script; usage: ./decrypt.exp doc 1234:
#!/usr/bin/expect -f
set filename [lindex $argv 0]
set passphrase [lindex $argv 1]
spawn gpg --output $filename --decrypt $filename.gpg
expect -exact "Enter pass phrase: "
send -- "$passphrase\r"
expect eof
Import:
keys can be imported into either key-chain with:
gpg --import somekey.sec
gpg --list-secret-keys
gpg --import somekey.pub
gpg --list-keys
there barely is anything to automate; however setting an imported key as "trusted" would require expect for automation. found this cheat-sheet, which has all commands on one page; and it also hints for: If you have multiple secret keys, it'll choose the correct one, or output an error if the correct one doesn't exist (which should confirm my comment below).
file ~/.gnupg/options is a user's options file; where one can eg. define the default key-server.
Since version 2.1.14, GPG supports the --recipient-file option, which lets you specify the public key to encrypt with without using the keyring. To quote the developer:
It is now possible to bypass the keyring and take the public key
directly from a file. That file may be a binary or an ascii armored
key and only the first keyblock from that file is used. A key
specified with this option is always fully trusted.
This option may be mixed with the standard -r options.
--hidden-recipient-file (or -F) is also available.
To futher assist some use cases the option
--no-keyring
has also been implemented. This is similar to
--no-default-keyring --keyring /dev/null
but portable to Windows and also ignores any keyring specified
(command line or config file).
So to encrypt, you would do:
gpg --output myfileenc --encrypt --recipient-file key.pub myfile
To automate, in addition to using expect or Python as explained in the other answers, you can also use the --batch option. (You will need to see which of the offered answers works best on your system).
No such option, however, is available for the secret key, and, as a matter of fact, the same version of PGP (2.1) deprecated the secring option in the --generate-key command, so this file is not even available any more. The generated key will need to be added to the keyring to be used for decryption.
I am wondering what are the GUID suffixes for the RSA key container files stored in the machine and user key container stores. I cannot identify some of these as key containers through CAPI/CNG, although I'll expose my case using command line tools instead. Commands below are for PowerShell in an elevated prompt. On most machines, the GUID suffix is the same for all these file names, but on this one there are four different GUIDs, while the API is returning only keys with only one. What is this GUID? I do not like random secrets stored by I do not know what on my machine; are they safe to delete?
The content of the machine store directory is:
> ls -n $env:ProgramData\Microsoft\Crypto\Rsa\MachineKeys | sort { "$_"[-3..-1] }
d1f9044f5d7345da71c0d2efd2e4f59e_e9f96f2e-b8b7-49b2-85a5-840195eca603
d6d986f09a1ee04e24c949879fdb506c_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
6de9cb26d2b98c01ec4e9e8b34824aa2_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
76944fb33636aeddb9590521c2e8815a_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_c6a7fc9d-32a6-41e4-afd5-7dc7b822029e
I sorted the list by the last three characters, so that it's easy to see in a glance that there are 4 distinct GUID suffixes to the key container files. Now let's enumerate the key reported by all installed CSPs. I'll get the list of providers, and later the list of each provider's keys using the certutil tool that comes with Windows. Its output requires some regex magic for parsing, which is not essential, just convenient:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value }
Microsoft Base Cryptographic Provider v1.0
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Base DSS Cryptographic Provider
[...snip...]
The output for a single key lists the name, flags and the key container ID, the latter matching respective file name in the above directory (of course, we can see more keys from additional KSPs, smart cards, TPM etc.). Example for one provider (the -q makes some providers fail silently instead of asking for user's action, such as inserting a SmartCard):
> certutil -key -q
Microsoft Strong Cryptographic Provider:
iisConfigurationKey
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
RSA
AT_KEYEXCHANGE
iisWasKey
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
[...snip...]
Some key names are just GUIDs too, but if we grep out only the lines that start with at the least 20 hex digits, there will be only the IDs listed. So all key IDs from all providers can be concisely shown with:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ certutil -key -q -csp "$_" } | sls '^\s+[0-9a-f]{20}.+' | sort -u
597367cc37b886d7ee6c493e3befb421_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
f0e91f6485ac2d09485e4ec18135601e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
Here are actually 2 more keys than there are in the MachineKeys directory (they come from the KSP, in fact, certutil -key -csp KSP shows them, if you are wondering). But the fact is they all have the same GUID suffix _f7fe3b04-ef9b-4b27-827f-953c5743e2ec.
The machine was installed by the vendor (an HP notebook, to be exact). This is unlike other machines, that we assemble or buy barebone and install and configure by ourselves. And I am working with some sensitive data sometimes, so I am indeed paranoid vetting the software thoroughly before allowing machines to access sensitive data.
The OS is Windows 10, if that matters, but the same type of storage has not changed from Windows 7, AFAIK, even with the introduction of the new CNG API in 8.0 (or 8.1?).
Just in case anyone would find useful a PowerShell snippet to readably list keys by provider, I used this command:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ Write-Host -for Yellow "`n$_"; certutil -key -q -csp "$_" }
Found the answer here: https://serverfault.com/a/642279/451491
The file naming convention is x_y, where x is a random GUID to
uniquely identify the key, and y is the machine GUID found at
HKLM\SOFTWARE\Microsoft\Cryptography.
I'm trying to get the fingerprints from the public OpenPGP keys of ActiveMQ. They are published at http://www.apache.org/dist/activemq/KEYS.
Unfortunately, not all the keys have fingerprints listed next to them. Do you have any idea how to proceed?
I used this command (tested with gpg 2.2.12):
gpg --show-keys file.pub
For old versions, see the answer from Jens Erat. With newer versions gpg --with-fingerprint does not work and returns:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
The fingerprint is derived from the public key and creation timestamp -- both are contained in the public keys listed on the site.There are several ways of inspecting keys without importing them, which also makes sure you print the information of the very specific key you are considering right now. --with-fingerprint makes GnuPG always output the fingerprint when listing keys. One way to get the fingerprint would be:
$ gpg --with-fingerprint <<EOT
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.1 (Darwin)
mQGiBEPspSsRBADdguKAxMQbA32vTQrCyONR6Zs/YGdvau2Zrr3SSSSR0Ge4FMjZ
4tzwpf6+32m4Bsf7YIwdLl0H5hI1CgT5gDl9kXvfaFUehFnwR+FDyiBRiyHjUpGF
4dgkQfWy9diYeWGtsvszsvWHXtED4SXb322StX4MfJj+YesA1iEdTiXK6wCg1QDa
RucfjC+kx4zPsJwkJOgYpyMEAMTiXtNwQcke6nIFb/lb5374NjwwVAuuMTrRWLyq
5HodugEIHaw3EitQWtnFfXNkXTJZzS6t2HAGv29UTfhiBzKdkydgCkOk2MLWISOV
fqcg0tNIp5ZJCmUHg3s+OFNSH4oUi65u+FyDseUid3OKtPI+ZhIk8N+DjOIg2Kvo
/UALA/9q+WfBd7re+W3iUtU7TutUcwbKsjP+jpaJeUHg2ChOBxVfQKt4YlPHVdrR
iCrfNi90Z8qbsZ0iAXuqexrfMq20pAPmpHRpe54mmP1CMT5m+Gq71eKIfkUrb3LC
/zv08dLG2vm9oghd242wbcifaX+t7AhNAIpe/WTvQsB0gpdO4LQmSGlyYW0gQ2hp
cmlubyA8aGlyYW1AaGlyYW1jaGlyaW5vLmNvbT6IWwQTEQIAGwUCQ+ylKwYLCQgH
AwIDFQIDAxYCAQIeAQIXgAAKCRCf8lmA9bp+T/G/AKDM1QDs7il/CJhTycgDvE3c
EOgUBwCfelsVK4sgBCooZptoaCCDgVtt71G5AQ0EQ+ylLhAEAJD25AWgwcNgBFKY
svExQaGIojIGJyn4Cf/5U30cui/K7fIU7JtyNhKcfZdCrh2hKx+x3H/dTF6e0SrR
hzKV7Dx0j76yhHHB1Ak25kjRxoU4Jk+CG0m+bRNTF9xz9k1ALSm3Y+A5RqNU10K6
e/5KsPuXMGSGoQgJ1H6g/i80Wf8PAAMFA/9mIxu7lMaqE1OE7EeAsHgLslNbi0h9
pjDUVNv8bc1Os2gBPaJD8B89EeheTHw6NMNIe75HVOpKk4UA0gvOBrxJqCr18yFJ
BM5sIlaEmuJwZOW4dDGOR1oS5qgE9NzpmyKhE+fu/S1wmy0coL667+1xZcnrPbUF
D4i7/aD1r8qJhohGBBgRAgAGBQJD7KUuAAoJEJ/yWYD1un5Pth0An0QEUs5cxpl8
zL5kZCj7c8MN8YZDAKDR9LTb6woveul50+uGtUl2fIH1uA==
=RBPl
-----END PGP PUBLIC KEY BLOCK-----
EOT
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub dsa1024/0x9FF25980F5BA7E4F 2006-02-10 [SCA]
Key fingerprint = E5B8 247A F8A6 19A2 8F90 FDFC 9FF2 5980 F5BA 7E4F
uid Hiram Chirino <hiram#hiramchirino.com>
sub elg1024/0x10314D676733C080 2006-02-10 [E]
You can also provide the full page, then GnuPG will print all fingerprints, readily grepable.
Note, that this works only on old GnuPG, version 2.0.x. For newer versions, see the other answers describing the --show-keys option, which is not available in this version.
gpg --show-keys --fingerprint <<EOT
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.1 (Darwin)
mQGiBEPspSsRBADdguKAxMQbA32vTQrCyONR6Zs/YGdvau2Zrr3SSSSR0Ge4FMjZ
4tzwpf6+32m4Bsf7YIwdLl0H5hI1CgT5gDl9kXvfaFUehFnwR+FDyiBRiyHjUpGF
4dgkQfWy9diYeWGtsvszsvWHXtED4SXb322StX4MfJj+YesA1iEdTiXK6wCg1QDa
RucfjC+kx4zPsJwkJOgYpyMEAMTiXtNwQcke6nIFb/lb5374NjwwVAuuMTrRWLyq
5HodugEIHaw3EitQWtnFfXNkXTJZzS6t2HAGv29UTfhiBzKdkydgCkOk2MLWISOV
fqcg0tNIp5ZJCmUHg3s+OFNSH4oUi65u+FyDseUid3OKtPI+ZhIk8N+DjOIg2Kvo
/UALA/9q+WfBd7re+W3iUtU7TutUcwbKsjP+jpaJeUHg2ChOBxVfQKt4YlPHVdrR
iCrfNi90Z8qbsZ0iAXuqexrfMq20pAPmpHRpe54mmP1CMT5m+Gq71eKIfkUrb3LC
/zv08dLG2vm9oghd242wbcifaX+t7AhNAIpe/WTvQsB0gpdO4LQmSGlyYW0gQ2hp
cmlubyA8aGlyYW1AaGlyYW1jaGlyaW5vLmNvbT6IWwQTEQIAGwUCQ+ylKwYLCQgH
AwIDFQIDAxYCAQIeAQIXgAAKCRCf8lmA9bp+T/G/AKDM1QDs7il/CJhTycgDvE3c
EOgUBwCfelsVK4sgBCooZptoaCCDgVtt71G5AQ0EQ+ylLhAEAJD25AWgwcNgBFKY
svExQaGIojIGJyn4Cf/5U30cui/K7fIU7JtyNhKcfZdCrh2hKx+x3H/dTF6e0SrR
hzKV7Dx0j76yhHHB1Ak25kjRxoU4Jk+CG0m+bRNTF9xz9k1ALSm3Y+A5RqNU10K6
e/5KsPuXMGSGoQgJ1H6g/i80Wf8PAAMFA/9mIxu7lMaqE1OE7EeAsHgLslNbi0h9
pjDUVNv8bc1Os2gBPaJD8B89EeheTHw6NMNIe75HVOpKk4UA0gvOBrxJqCr18yFJ
BM5sIlaEmuJwZOW4dDGOR1oS5qgE9NzpmyKhE+fu/S1wmy0coL667+1xZcnrPbUF
D4i7/aD1r8qJhohGBBgRAgAGBQJD7KUuAAoJEJ/yWYD1un5Pth0An0QEUs5cxpl8
zL5kZCj7c8MN8YZDAKDR9LTb6woveul50+uGtUl2fIH1uA==
=RBPl
-----END PGP PUBLIC KEY BLOCK-----
EOT
pub dsa1024 2006-02-10 [SCA]
E5B8 247A F8A6 19A2 8F90 FDFC 9FF2 5980 F5BA 7E4F
uid Hiram Chirino <hiram#hiramchirino.com>
sub elg1024 2006-02-10 [E]
From GPG manual -
--show-keys
This commands takes OpenPGP keys as input and prints information about them
in the same way the command --list-keys does for locally stored key. In ad‐
dition the list options show-unusable-uids, show-unusable-subkeys, show-nota‐
tions and show-policy-urls are also enabled. As usual for automated process‐
ing, this command should be combined with the option --with-colons.
--fingerprint
List all keys (or the specified ones) along with their fingerprints. This is
the same output as --list-keys but with the additional output of a line with
the fingerprint. May also be combined with --check-signatures. If this com‐
mand is given twice, the fingerprints of all secondary keys are listed too.
This command also forces pretty printing of fingerprints if the keyid format
has been set to "none".
--with-fingerprint
Same as the command --fingerprint but changes only the format of the output
and may be used together with another command.
My GnuPG version is 2.2.20
References -
https://unix.stackexchange.com/a/694646/356166
I am wondering how to extract keys from an Apple .p12 file. From my limited understanding, a .p12 file is a combination of X504 certificates and private keys.
I am seeing that every .p12 file I run into has a X504 certificate and at least one key, and in some situations two keys. This is due to the fact that every .p12 has an Apple developer key, and some have an extra key (possibly an Apple root authorization key). I am considering only those .p12 files with two keys as valid. My goal here is to differentiate between those .p12 files that have one key and those that have two.
So far I have used OpenSSL to be able to inspect X504 files and the keys of any .p12. For example I have this code that does the inspections for all .p12 files in a directory:
Dir.glob('*.p12').each do |p|
file = File.read(p)
p12 = OpenSSL::PKCS12.new(file, "")
# note that this new certificate is in an X509 format
cert = p12.certificate
puts p12.inspect()
puts cert.inspect()
end
This is my output:
#<OpenSSL::PKCS12:0x007fcf33018920>
#<OpenSSL::X509::Certificate subject=/UID=FFBMT4K5/CN=iPhone Distribution: A.H. Belo Management Services, Inc./OU=FFBMT4K5/O=FFBMT4K5/C=US, issuer=/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority, serial=36597980220620, not_before=2012-01-11 16:30:22 UTC, not_after=2013-01-10 16:30:22 UTC>
Now my problem is getting keys. If I do something like this:
puts p12.key
I get a long string on encrypted data like this:
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA4Pet7CZrPr4x/SKjMwy5avXmcguzQlix/vBq+qq7aKQhctKr
d5HE7wk4jWbDGj7Rf9ckeFFMktTTbKYmnKCywCct/uJmgavFl1+t45DIQL2V1JMU
JSXvtjDXoKFweKQgdiha5mBNL70+ivqxMzJJw19E+MhFoZ6tFOgQ5gPLcDLR5WTU
ezxH9RbXGWbq+CMBjJ+lw8/Ako7IOm+d95ZTM6u333qp0dsn+1/I/zGeWE1gJXIl
8mIkvrp7+BDTvXHYALADwXnXijqvd/bANfetsDQ+gxRnc06dFt114JUuptcXGwbg
//ykDzNYhuibQD1Z65KfTB/ntQ1aE5FtHEXirwIDAQABAoIBACNCrt/0pZqP9QXY
B/xYYjeBkz0M2GvtuvhadmoTmIwuLY/xtS5oipVsvJBtKudSMUP4VJ8HHxlkgj7l
S+gAyAOWIH9yvN5WLgIr3PVuG/UJwhIve1jXOVs1DJcAtsAx+WSLrrOtJGv3HXZr
FJsRpr4YkJbtzPwoArjkJsHmllxfT2zeQPMJy+RQ/qlHUqsude/ahC0I3RiW3SgB
EKTNM1vGTEkox8bUUhHqNY3ERlihFpZC2wSkroETDY3RkSjuPkNy7uT/b66a/qjj
qaIA0YLhNOYGdN2llJN5GJjYYVKakpiipqcHCFrV1+JtbFB2tKhqAvK6fjCZcSFF
fW58owECgYEA/g8FvAPcejPR3O8E1ydNWChhd9UZQUeQNCET+lY3Dxwklk+u1140
yw/u2hUoNdJLfev1HtlYruglD9jW/LGoLaPodQfcHcaCSfdJa1mmKfSieApOe15+
ijO3WpZK/MJUTteGVMW/B/QnxPBGtsDo6q2v2YxA7fOhzmImn5hgxlsCgYEA4q/A
DBKe1WDZPUyG3R/Cfl5AEqEHly6VkCPFF+uYFZzep/SN/ez34r7fmcfl0RL7H9kn
Q4WBaCMbCgG9dErORW99usoBsjys5pojstNJDZwACUg9rPnV/+uUqMyocjeN0Vrl
2Vg0dC8HH1hLZPLkp+MAy2nNzmnnHcTKiTqsDT0CgYEApVzfzaXxvvS1t4k37Fbf
h+8YqefhfVT4LoYNO9ccFVCrG88XrYTa9gUT4Yz91DJiAr8vl/m+OHJPlUX9gRKd
tb9HEc2g3xyTN1OmzSHX/t0FVv7WYIR79rZ8tJC4lFZki8DK5aikk6e+rvf5/wAH
WqDcocwhgwAeJHhMTXrgGpsCgYBGYqWx2fJBdNHfK6zQafUdAazJXACcW5WK7OBc
vgU56Lxl0BRqnLKXUAbjm+Lq2Qbqa6W6XHDC4euaXtHxkuybOLQEVIbUTeytqXye
IOaU+DQ2rZyg4e4liYNeKjW/SSqar6ugobefv55piCPY02ZWDrEHd/G0PsPJRXpR
w8r6TQKBgFMoEZKywokRIbMCUHHRR3TVeizBMhbNUUmOiRhzsHZPJ2V63PNp3L1c
0NsRo62mbekXDRH8J0C8fLG4R64Y7+rHBQo0tBpgYepPU0NCrsojF7brtYYb3VqI
baVEPRhIy2tJylDad6M36DeOCIhvXalh8GaV/HhEr4lxykth+mGH
-----END RSA PRIVATE KEY-----
My question is how can I determine whether this certificate has more than one key, and also how I can inspect the keys for information. If what I am asking or my understanding of this issue is fundamentally flawed, please let me know. This is my first time being exposed to certificates and any information will be greatly helpful. Any points in the right direction will be appreciated, thanks in advance.
EDIT:
Using OpenSSL I can view the two shrouded keybags of a .p12. Example:
openssl pkcs12 -in some_p12.p12 -info -noout
output:
Enter Import Password:
MAC Iteration 1
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
So I'm looking for a couple things. Generally speaking, what exactly are these keybags? And also, how can I inspect them/determine how many I have per .p12 file using Ruby. Thanks.
I'm quite late for this one but it also interested me. I've tested creating a p12 file using two of my digital certificates (one expiring in 2023 and the other one in 2027) and this is was the openssl output:
$ openssl pkcs12 -in some_p12.p12 -info -noout
Enter Import Password:
MAC Iteration 1
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048*
When parsing it in ruby using OpenSSL::PKCS12 I noticed one of the certificates could be read from the in ca_certs array and the other from the certificate method:
p12 = OpenSSL::PKCS12.new(file, "1234")
p12.certificate # => The latest one with the further expiry date (2027)
p12.key # => The private key from the certificate
p12.ca_certs # => Array, with the other certificate (expiring in 2023)
p12.ca_certs.count #=> 1
I could read the private key from the certificate using key as usual, however I could not find a way to read the key corresponding the certificate from ca_certs
A .p12 contains only 1 private key, and contains 1 or more public keys. The public keys are the ones that make the chain of trust.
.p12 is a binary format. To convert it and extract to individual certificates, look for example here. The link contains all the openssl commands you need.