Need help regarding keystores.
I have 2 .p12 files (we'll call them phil.p12 and grant.p12 for now).Both have different individual passwords.
I want to merge these into a single .p12 keystore for use in a Jmeter script where the different keys need to be called on depending on the case being executed.
Can anyone help me do this and give some advice on managing this?
For instance:
1) Is this even possible?
2) How do I deal with the fact that each individual cert has a different password?
Any help gratefully received.
It is possible. You can use the keytool -importkeystore command to import an entire keystore into another keystore. So the command you need to run would look like
keytool -importkeystore -srckeystore {SOURCE_KEYSTORE.p12} -srcstoretype pkcs12 -srcstorepass {PASSWORD} -destkeystore {DESTINATION_KEYSTORE.p2} -deststoretype pkcs12 -deststorepass {PASSWORD}
You can have different passwords for your two different P12 keystroes. But for each keystore, the key pair entry's password (key password) should be the same as the keystore's password.
The internet standard of a P12 is:
It has only 1 key pair entry in it (of course, it can hold more than 1).
The key pair entry's password (key password) is the same as the keystore password.
Related
I would like to execute the below curl command and specify my own key store.
I tried using --cacert option and specified the path of the cacert jks.
curl --ssl-reqd --url 'smtp://mailhost.myorg.com:587' --user 'usrid:pwd' --mail-from 'fromaddr#myorg.com' --mail-rcpt 'toaddr#myorg.com' --upload-file mail.txt -vv --cacert /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.272.b10-1.el7_9.x86_64/jre/lib/security/cacerts
But it resulted in an error.
curl: (77) Problem with the SSL CA cert (path? access rights?)
As Amit quoted, curl --cacert requires a file in PEM format -- but the Java cacerts file is in JKS format, which is massively different.
You can convert the certs from JKS format to PEM format with a script, something like:
jks=/usr/lib/jvm/$javaversion/jre/lib/security/cacerts
for c in $(keytool -keystore $jks -storepass changeit -list | awk -F, '/trustedCert/{print $1}'); do
keytool -keystore $jks -storepass changeit -exportcert -alias $c -rfc
done >pemfile
# for Java9 up use -cacerts instead of -keystore $jks
which maybe makes this marginally on-topic for SO, since your Q isn't about programming at all. Instead of doing all the certs you could do a selected one, or few, that are needed for the connections you want to make and validate.
But for RedHat (as tagged) this isn't necessary. In RedHat (and RH-based) Open JDK packages JRE/lib/security/cacerts is actually a symlink to /etc/pki/java/cacerts which is supplied by a different package ca-certificates.noarch -- which also supplies the same certs already in PEM format in /etc/pki/tls/cert.pem so you could use that directly (in spite of the name appearing singular it actually contains, or rather links to a file containing, many certs) AND in NSS format in /etc/pki/nssdb/* which is what the RH package of curl uses by default. Thus your curl already by default uses the same certs you can get from the Java cacerts file, so this effort accomplishes nothing at all.
when using --cacert you need to specify the certificate - e.g - /tmp/ca.crt
From the docs:
--cacert (HTTPS) Tells curl to use the specified certificate file to verify the peer. The file may contain multiple CA certificates. The
certificate(s) must be in PEM format. If this option is used several
times, the last one will be used.
--capath (HTTPS) Tells curl to use the specified certificate directory to verify the peer. The certificates must be in PEM format, and the
directory must have been processed using the c_rehash utility supplied
with openssl. Certificate directories are not supported under Windows
(because c_rehash uses symbolink links to create them). Using --capath
can allow curl to make https connections much more efficiently than
using --cacert if the --cacert file contains many CA certificates. If
this option is used several times, the last one will be used.
So, if you specify --cacert, the CA certs are stored in the specified file. These CA certificates are used to verify the certs of remote servers that cURL connects to.
The --capath option is used to specify a directory containing the CA certs rather than a single file.
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
i have to connect to a webservice, where a pkcs12 certificate is a must. the idea was to use curl in a bash script (under OS X, to be specific).
i have learnt that one of the few things curl cannot do in communication, is handling pkcs12 certificates (.p12). what are my options?
i have read that converting the certificate to PEM format would work (using openssl), however i have no idea how to tell curl that it gets a PEM and should communicate with a webservice requesting PKCS12 certificates.
converting pkcs12 to pem would be done like this (e.g.), it worked for me, however i haven't successfully used them with curl:
openssl pkcs12 -in mycert.p12 -out file.key.pem -nocerts -nodes
openssl pkcs12 -in mycert.p12 -out file.crt.pem -clcerts -nokeys
any hints? or, any alternatives to curl? the solution should be commandline based.
I think you have already resolved but I had the same problem. I answer to share my solution.
If you have a .p12 file your approach is right.
First of all, you have to get the cert and the key separated from the p12 file.
As an example, if you have a mycert.p12 file execute
openssl pkcs12 -in mycert.p12 -out file.key.pem -nocerts -nodes
openssl pkcs12 -in mycert.p12 -out file.crt.pem -clcerts -nokeys
Then you have to make the call to your url. For instance, assume that you want to get the WSDL of a specific web service
curl -E ./file.crt.pem --key ./file.key.pem https://myservice.com/service?wsdl
If the files file.crt.pem and file.key.pem are in your working folder "./" is mandatory.
Check if you have a newer curl. Newer versions can handle PKCS12 outright.
Tangentially, quote the password, or individually escape all shell metacharacters.
curl --cert-type P12 --cert cert.p12:'password' https://yoursite.com
bioffes answer is correct.
He was suggesting to do:
curl --cert-type P12 --cert cert.p12:password https://yoursite.com
For some reason that didn't work for me. I was getting:
curl could not open PKCS12 file
I just ended up exporting the p12 file without a password and ended up just using the following format.
curl --cert-type P12 --cert cert.p12 https://yoursite.com
You can easily check to see if your curl can handle p12. Very likely it does. Just do man curl and scroll down til you find the cert-type. Mine was like this:
--cert-type <type>
(TLS) Tells curl what type the provided client certificate is using. PEM, DER, ENG and P12 are recognized types. If not specified, PEM is assumed.
If this option is used several times, the last one will be used.
(I don't believe cmmd + F works to text not visible in the terminal. So you have to scroll down.
I'm trying to create certificate request through below command line and returned with error:
./runmqckm -certreq -create -db
/var/mqm/qmgrs/QMGR01/ssl/sslreceiver.kdb -pw password123 -label
ibmwebspheremqsslreceiver -dn "CN=SSLCLIENT,O=IBMIBM,C=US" -file
/var/mqm/sslreceiverreq.arm
The keystore already contains an entry with label
'ibmwebspheremqsslreceiver'.
Choose a different label and try again.
However, there is no such entry as ibmwebspheremqsslreceiver in my current keystore file,
**#/usr/mqm/bin $ ./runmqckm -cert -list -db
/var/mqm/qmgrs/QMGR01/ssl/sslreceiver.kdb -pw password123
Certificates in database /var/mqm/qmgrs/QMGR01/ssl/sslreceiver.kdb:
ssl_ca
So why this happened?
The first command creates a certificate request.
The second command lists certificates.
If you want to list certificate requests, use the -certreq -list command instead of the -cert -list command.
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.