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.
Related
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.
I am building an auto build script for generating applications. Before I ran every command manually. The build script is almost finished, but there is a problem. Some commands require input, but I don't know how to provide input to the commands without prompting the user. For example:
keytool -genkey -v -keystore Keystore/$name.keystore -alias $lowername -keyalg RSA -keysize 2048 -validity 10000
This asks for the current password which is always the same, but I need to enter this every time.
Is there a way I can provide the answers to the questions I get when running the command without showing this to the user?
You can use the program expect (part of a TCL extension library) to achieve this.
It is pretty trivial to use.
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 need to script the export of a cert from our Windows store into Firefox. I am having trouble getting the cert into the correct "container". The certificate, as generated from a command line as well, is a .pfx file with a password. I can manually import the cert into Firefox under the "Your Certificates" tab of the Certificate Manager. However, when I run the command line, it dumps the cert under the tab labeled "Others" and the website we're trying to access either can't find the cert there or there's a problem with the import itself.
My first couple of attempts failed with errors, but following up on them I found a site that suggested I convert the .pfx file to a .pem file. I followed those instructions and the command line now runs without error. The other thing to note here is using the GUI, I cannot import the .PEM file, but I can import the .PFX file.
Assuming that the .pem file is encoded and formatted correctly, how can I get this line of code to put the cert into the right container?
certutil -A -n "My Certificate" -d c:\temp\CertImport -t "CTu,," -u "c" -a -f pword.txt -i CertEric.pem
(I added the '-f' argument in case its needed to import the password protected file. I've run this both with and without it and got the same results.)
I also exported the cert in a .cer format.
Here are some other attempts and results:
certutil -A -n "My Certificate" -d c:\temp\CertImport -t "CTu,," -u "c" -a -f pword.txt -i CertEric.pfx
certutil: could not obtain certificate from file: security library: improperly formatted DER-encoded message.
certutil -A -n "My Certificate" -d c:\temp\CertImport -t "CTu,," -u "c" -a -f pword.txt -i CertEric.cer
certutil: could not obtain certificate from file: security library: improperly formatted DER-encoded message.
(Although, dropping the '-a' argument allowed this command to complete without error.)
certutil -A -n "My Certificate" -d c:\temp\CertImport -t "CTu,," -u "c" -f pword.txt -i CertEric.pfx
certutil: could not obtain certificate from file: security library: invalid arguments.
(This one uses the .pfx file and drops the '-a' argument)
Any ideas? Thanks for your time.
Eric
I just posted a solution to StackOverflow that you might find helpful.
Our certificates are in .cer format and work fine
Programmatically Install Certificate into Mozilla
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.