How can I verify an X509 (or DER-formatted) certificate against the Java certificate store via the command line?
I've looked into using the keytool utility, but it looks like it only handles import/export/display functionality (no verification).
EDIT: It looks as though keytool can be used for verification, but only if an import is attempted. I suppose a better way of asking this questions is whether or not a more passive approach (as in: not modifying the keystore) is available. Thanks!
You can use keytool to export the needed certificates (those that are in the chain for the one you need to verify) from the Java keystore into X.509 files. Then, concatenate them together into one file. Finally, use openssl to do the verification.
openssl verify -CAfile concatenated-certs.crt cert-to-verify.crt
Not a perfect solution since it involves popping the certs out of the truststore, but it ought to work given what you are starting with.
This page could be oversimplifying:
http://java.sun.com/docs/books/tutorial/security/toolfilex/rstep1.html
But it doesn't look like even import with keytool does a true verification of a certificate. I'm not seeing any description of verifying the signature of the incoming certificate against the signature of another trusted certificate.
jarsigner will verify a signature on a signed jar, but doesn't do anything to verify the signature on the certificate used to sign the jar.
I'm afraid you'd either have to write a tool to do the verfication, or look for a commercial tool that does it. I would think that some of the PKI tool kits would have a certificate verification tool that would do this.
Related
Looking for a direct way how to check whether a certificate is self-signed (not self-issued).
The certificate don't have the Authority and Subject Key Identifiers.
From this answer (https://security.stackexchange.com/questions/93162/how-to-know-if-certificate-is-self-signed), it is possible to check it via openssl command:
openssl verify -CAfile /cert/to/check.pem /cert/to/check.pem
I need to check it in the simplest way possible, probably with java.security package. Is this even possible?
I'm trying to use a Web Service but I have many doubts about the certificates, I'm quite a novice in this topic, The team that developed the web services sent me a document where explains how to use it but to enable the connection, I need to USE a certificate (X.509), I generated p7b certificate from they website and I imported that certificate in my local environment, Using Keytool -import it generate a JKS file but they warn that I should install "Entrust" (Root and Intermediate) certificates that they provide me I used keytool -import with these .cer files and the command generated one .JKS for each file, I installed those cer too, my question is:
To use that web service Which certificate file I need to attach in my implementation logic in java, the jks or p7b ?
How I can use this certificate in all the Test environment? (I don't know if this certificate can be use only in the PC that generates the CSR).
I'm trying to simulate the call with the SOAPUI app i'm getting the authentication error so Probably something is worng with the certificate.
He implemented all using windows certificate store and .NET they can't give me support for keytool.
To do client authentication (also called mutual authentication) in SSL/TLS you (your program) needs not just a certificate but a certificate PLUS PRIVATE KEY and usually intermediate/chain certs. There are canonically 5 steps in the process:
On your computer generate a key PAIR which consists of a privatekey and a publickey, and a Certificate Signing Request (CSR) which contains the publickey. These steps may be done separately, or combined in a way that you don't notice there are both a CSR and a privatekey.
Submit the CSR to a Certificate Authority (CA) along with evidence of your identity and authorization as appropriate, and payment if the CA requres it.
The CA issues an 'end-entity' certificate (in this case a client cert) containing your publickey and identity(ies) plus some other information and gives you this certificate, usually along with an intermediate certificate or sometimes a few intermediate certs that form(s) a 'chain' from the entity cert to a trusted CA root or anchor cert. A 'p7b' file is one fairly common way, though not the only one, of transporting a group of related certs, such as your entity cert plus your chain cert(s).
You return the entity cert and the chain cert(s) to your computer and combine with your privatekey from step 1.
You use the combination of privatekey PLUS certificate chain with various program(s) such as a browser, a utility like curl, or a custom application.
Details of steps 1 and 4 (and 5) depend on the systems and software you use, which you don't specify in any recognizable way, although it sounds like you are ending up in the Windows certificate store. If that is the case, and it is specifically the Personal section of the current-user store (as opposed to a machine account like SYSTEM), then when you run MMC (aka Administrative Tools) and select the Cert Mgr addin, or directly run certmgr.msc, the icon for the cert should have a yellow key at the left:
Contrary to your Q, Java JCE (at least Oracle-was-Sun Java on Windows) can handle this; run keytool -list -storetype Windows-MY -keystore NONE and see for yourself.
However, some (probably many) Java programs cannot. For those, you need a keystore file containing the privatekey PLUS certificates; to create that run the Export wizard and select 'Yes, export private key', then format PKCS 12 (aka PFX) with 'include ... path'.
Recent updates of Java 8 by default can automatically handle a PKCS12 keystore (look for keystore.type.compat=true in JRE/lib/security/java.security) and older versions can do so if the program configures the store type (I don't know if SoapUI does that). For older versions that require JKS, after exporting to PKCS12 to let's say mykey.p12 convert with
keytool -importkeystore -srcstoretype pkcs12 -srckeystore mykey.p12 -destkeystore mykey.jks
What you try to archivee is something called a mutual-authentication. In order to understand the basics you need to understand that the humans have simply concepted a password to lock and unlock informations by the same (symetric) password. Everyone who knows the one password can
read the message
rewrite the message to send false informations
this is dangerous. So they have invented two different passwords, one for writing (private) and a compleatly different one for receive(public), we call them asymetric. The problem in asymetric encryption was, that you can choose free only one password, the opposite password is calculated and can not be choosen freely.
Finally they invented certificates to simplify the process. Certificates contains strong Passwords packed into files. Without looking into the certificates you dont know if the passwords are private or public, that means p7b(pkcsv7b) and jks can contain the absolute same informations. The difference is the format only, like the difference between .doc and .docx.
The second problem
In the big japaneese war's spionage was a big thing, the agents gathered informations about the opposite at the point of tactics and send theese informations to their real lords to find weaknesses in the tactics/strategys. Whenever a spoin has been uncovered he has been turned into a double-agent faking honeypots to let the warlord make wrong decisions and fall into traps.
So as an warlord you must trust your agent ... but, how to be sure? Well, you can ask the other agents about the agent you have the informations from to have the guarantee that the message can be trusted. So the first agent must ask other agents to sign the message too, this question between agents is the CSR! If the other agent(s) sign too, we have a "chain of trust". Ok we have four parties now, the agent, the signing-agent(s) the enemy(hacker) and you.
What must be placed where? Well, assuming you are a warlord (server),
you need the public passwords of all your clients(agents) in a truststore to send them messages(download),
you need to know your private password to encode messages(posts, requests, uploads) your agents sent.
Assuming you are a agent(client/browser) of a warlord inside the enemys lines (open field of world-wide-web), you must store:
your private key, to send messages and sign messages of other agents
the public key of the warlord to encode orders of your master.
You have learned now that a certificate can contain aswell private keys as public keys. How to technically use them?
You lucky, the keytools is open source, download the sources from grepcode (click here) and you will have your implementations by copy-and-paste.
Some hints for mutual-authentication:
The server should not offer its public certificate because all authenticated clients already have the public certificate(key) in their truststore.
The client's certificate should be sent in a non-electronic way (printed as rf-code or whatever).
The client should presented the server's public key and the clients private key in two seperate physical letters (you may noticed if you use the electronic-cash-card (ec-card) you had two letters, one for the PIN and one for the ec-card).
Some quick background on what I'm trying to do: a client is using a third party web service that requires mutual authentication. The service requires the client certificate be signed by a public certificate authority (ie: not self-signed). The client has some software written in Java that connects to the service, hence they used Java keytool to generate the original signing request and the key/certificate are stored in a jks keystore.
Our software that the client is going to be using is written in C#/.NET and will need to connect to the third party web service. As such we will we need to be able to access the client certificate.
I can't seem to find any way to export the certificate (along with private key) to either the Windows Certificate Manager or some other format that can be opened by .NET security libraries.
Exporting to a PKCS12 file does not work because keytool does not support it for trusted certificates (not sure if that is a keytool limitation or a limitation of the format).
I also found some Java code for getting the private keys, but I can't seem to figure out how I can get that into Windows Certificate Manager and associate it with the certificate. (How do I list / export private keys from a keystore?)
As a side note, the client doesn't want to generate a new certificate as there is a whole process involved in sending it to and getting it approved by the third party service they are connecting to.
Ultimately I'm hoping there are some commands I can run with keytool/openssl/etc that will allow the certificate & key to be exported/transferred into the Windows Certificate Manager (or some format that it can import).
(Sorry if my terminology is off or if some of this doesn't make sense. I kind of got stuck supporting this despite not being all that familiar with managing certificates.)
This seems to work for exporting the certificate but not the entire chain, the trick is to specify the srcalias:
keytool -v -importkeystore -srckeystore .keystore -srcalias mykey -destkeystore myp12file.p12 -deststoretype PKCS12
Thanks to Warren for pointing me to this: How to export private key from a keystore of self-signed certificate
I have never done https so far, but trying to get grips with it. I understand how to do self-signed certificates which is from what I understood is completely pointless as browsers will fire up straight away the warning. "As one cannot say trust me because I am honest."
From SO posts I understood that Tomcat or any other server environment is responsible for configuration. All clear and good.
The confusion is how these certificate signed when not self-signed. In other words, how do I point my keystore to CA provider.
I am following guide:
http://consultingblogs.emc.com/richardtiffin/archive/2010/10/15/applying-ssl-to-a-spring-web-application-on-tomcat.aspx
The problem is that I don't know what happens after I buy certificate from CA. Do I get a file which I need to point my keystore to or I import keystore itself remotely?
For self-signed we do:
"
Generating a keystore file (Self Certification)
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured, to-do this we'll use the keytool provided as part of JDK 1.6, the following should create the keystore :-
From your Java installation directory %JAVA_HOME%/bin
keytool -genkey -alias emc -keypass password -keystore emc_tomcat.bin -storepass password"
This implies that for not self-signed the details must come from CA provider? So need to add something to the line(URL path?)? Or is it the client responsibility to verify whether my certificate is valid...then how do I link my certificate to the one I purchased. I am completely confused.
Rephrasing other way: how to install CA from official CA providers?
Or I am telling complete rubbish and missing something fundamental. :-)
My apologies if there is duplicate, I've spent quite good bit of time of researching SO and reading wikipedia articles, but the internal mechanics are very difficult for novice users. I've marked bold the actual questions for people short on time. Thanks.
All the information you are asking for is readily provided by any reputable ("trusted") CA. See for example http://www.digicert.com/ssl-certificate-installation.htm
Quoting:
After you create your CSR, purchase your certificate, and the SSL
Certificate validation and processing are complete, you are ready to
install your SSL Certificate(s).
Your certificate will be provided via email or will be available to
download in your DigiCert Management Console. The SSL Certificate is a
text file with encrypted data that your server will use once the
certificate is installed
And following down the Tomcat link:
Tomcat SSL installations can be a bit tricky, but don't worry. Our
knowledgeable support staff is familiar with both the keytool utility
as well as common Tomcat installation methods. We will be happy to
help you generate your Certificate Signing Request (or CSR), install
the certificate to your Java keystore, and configure your server to
use it via either the Tomcat Admintool utility, or by editing the
server.xml configuration file directly.
It seems that this answers all your questions... "buy it and you will see how easy it is".
Suppose I have an application which in some way retrieves a client certificate (private/public key pair) at runtime via a secure channel (so I don't have this client certificate at build time).
How can I use this client certificate for client authentication without using keytool and not using some on persistent/ondisk keystore. So I do not want (actually I can't) to import it using a command line keytool?
Actually I want to replicate the functionality done in libcurl. You just set the client certificate (with private key) and your done. It doesn't involve a keystore.
All this has to be done in Java/Android.
You can do it in Java by defining your own KeyManager as described in the JSSE Reference Guide. I can't speak for Android.
I just got this working and I dont think you'll be very happy with my answer but it does work :)
So the hard part is to get the pkcs12 certificate you need to perform client authentication, if your certificate is already in pkcs12 then you've got all the hard stuff out of the way and you can refer to the second answer on SSL client authentication in Android to see how to use that certificate.
if you just have a public private key pair and not a pkcs12 certificate then you will need to make one. As far as I could tell there is no way in java/android to create this certificate so you need to use the android NDK and openssl.
if you download the openssl-android project from https://github.com/guardianproject/openssl-android you can use it to build openssl. By default it compiles as a .so shared object but only some of the android devices I tried to run this code on were able to link against libcrypto, so, although im sure there is a better way I went into the Android.mk files and replaced include $(BUILD_SHARED_LIBRARY) with include $(BUILD_STATIC_LIBRARY) in a few places so that I could compile a .a static library.
I then used the info from Android NDK: Link using a pre-compiled static library to link the libcrypto.a I compiled to my native code.
This native code uses openssl to first create an X509 certificate and then uses it to create a PKCS12 file which can be used in the manner I mentioned before located at SSL client authentication in Android
first you need to get your public and private keys into native land as EVP_PKEY pointers which can happen in a variety of ways based on what format your keys are in then you can use the following code to create an X509 certificate
X509 *public_key_cert = X509_new();
X509_gmtime_adj(X509_get_notBefore(public_key_cert),0);
X509_gmtime_adj(X509_get_notAfter(public_key_cert), (long) 60*60*24*365);
X509_set_pubkey(public_key_cert,evp_pub_key);
This creates the most minimally valid X509 certificate which is valid for 1 year. You may want to do other stuff like sign the certificate if you are going to run your own certificate authority, or set any of a large set of headers which contain various bits of information.
next you need to create the pkcs12 certificate using the X509 cert like this:
PKCS12 *pkcs12 = PKCS12_create(password, "Some Sort of Friendly Name", evp_priv_key, public_key_cert, NULL, 0, 0, 0, 0, 0);
password is a char* containing the password which will be used to encrypt the private key using triple-DES
Now that you have a pkcs12 certificate you can go over to SSL client authentication in Android and get client authentication going.
Good Luck!