I have a Certificate that has been added to a keystore using a KeyTool. I have also been provided private keys for use in Production / Test environment. I understand that the certificate is using a public key. Where do i place the keystore and the private keys to be able to be read by the command line programme. The following key reads the keystore.
System.setProperty("javax.net.ssl.keyStore", "xxx.ks");
System.setProperty("javax.net.ssl.keyStorePassword", "xxx_4ps!");
System.setProperty("javax.net.ssl.trustStore", "xxx.ks");
System.setProperty("javax.net.ssl.trustStorePassword", "xxx!");.
Where do i have to place the private keys to be read by the programme. I am new to public/private key encryption so any help would be appreciated.
Kind Regards,
Mateen
The private key and its corresponding certificate go in the javax.net.ssl.keyStore.
Certificates that you want to trust go in the javax.net.ssl.trustStore. Often you don't have one of your own, just use the default supplied with the JDK, in which case you don't specify this property at all.
These properties are pointing to certificates and just indirectly to keys. So, first you have to get certificates and put them into keystores.
"javax.net.ssl.keyStore" is used for keystore with certificate which is used to identify your system. By default, without any additional code, you can use just one identity certificate per keystore. To create a certificate, you have two options - one is to create self-signed certificate, another one is to create CSR and send it to certificate authority to sign.
See
http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html#selfcertCmd and
http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html#certreqCmd commands.
Once certificate is created, there will be private and public keys associated to it.
"javax.net.ssl.trustStore" points to the keystore with certificates which you trust. It means that your system will accept SSL connections only with certificates from this keystore or signed by the certificates from this keystore. These certificated can be added into the keystore using following command:
http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html#importCmd
You can put your keystores anywhere you like. Just ensure that java process has an access to them.
Related
I'm implementing a mutual authentication with a web server in Java on Windows.
I have a certificate on a SmartCard which is supposed to be used to authenticate me (or other user).
So far I've figured out that I can access the certificates using Windows-MY key store.
I do it like that:
KeyStore keyStore = KeyStore.getInstance("Windows-MY");
keyStore.init(null, null);
This works. I can see all certificates inside keystoreSpi (in debugger). One of them is the one which I need to use - I confirmed that.
The problem is as follows:
KeyStore api allows me to get a certificate only by using it's alias. e.g. keyStore.getCertificate("alias") or keystore.getCertificateChain("alias")
I noticed that there are multiple different certificates with the same alias in this keystore. I cannot change the aliases. I just physicaly got the smartcard with given certificates.
When I call one of the mentioned methods, keystore returns just the first certificate in the list with given alias. (generally, in the implementation there is a map where aliases are it's keys, so all duplicated aliases are ignored).
Unfortunately first certificate's purpose is "email encryption", etc. The second certificate's purpose is "SmartCard Logon" and this one I need to use. I confirmed that by going into debugger and manually hacking the list of certificates.
The question is: how do I get a proper certificate using the API (eg. the second one) when there are duplicated aliases?
If this can be done by external libraries, I can opt for that.
More details which may be useful:
I use KeyStore, then create KeyStoreManager.
I initialize SSLContext with given keyStoreManager sslContext.init(keyManagerFactory.getKeyManagers(), ...)
I create HttpsUrlConnection with given ssl context, which is my objective.
This has been fixed a while ago. Just update to a recent JRE. For more information see here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6483657
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).
I read this article on how to use keytool to generate CSRs for your organization. It was simple and easy, but left me with a few questions that I couldn't find clear, descriptive answers to:
What is Java's concept of a CSR alias and why would you want to use one? Where is this alias field stored and what other tools/APIs have access to it?
What is the difference between a key and a keystore?
What is Java's concept of a CSR alias and why would you want to use one? Where is this alias field stored and what other tools/APIs have access to it?
First of all, java uses keystores to keep keys (and certificates) inside. Single keystore can hold many certificates, so you need a way to differentiate them. That's what aliases are for. Having a keystore, an alias (and a password if needed) you can get the certificate from the keystore using Java Crypto API (specifically classes like Keystore). Here, you have a an example of how the Crypto API can be used to load a key from keystore
What is the difference between a key and a keystore?
The keystore is a container. The keys are kept inside keystores.
A keystore is a file format used to hold certificates and private keys, and alias is used to identify each entry in the keystore.
Hi I'm a bit lost and hope you'll get me out of here. I'll try to be as clear as possible since I don't really understand/know how I should use certificates.
I've got an application that is supposed to communicate with another one using webservices and SSL. We both asked our main "Certificate Authority" to get certificates.
They sent us 4 files and a password for the .P12 file:
.csr, .cer, .key, .P12
Here is what I did :
* Configure JBoss to use SSL on 8443 and used the P12 file as the keystore
To test this I did a small Java class that call a webservices on this server, using :
props.setProperty("javax.net.ssl.trustStore", "/.../.../certif.p12");
props.setProperty("javax.net.ssl.trustStorePassword", "XXXXXXXXX");
props.setProperty("javax.net.ssl.trustStoreType", "PKCS12");
The connection works, but I think I'm missing something as I did not use the other files.
If I send my .P12 file and the password to the application that is supposed to call my Webservices will it be ok/enough ?
Edit :
I forgot to mention that I should call a Webservice on the other application too, so it should be the other way around, do I only need a .P12 and pass ?
I've read a lot of thing about public key, private key, keytool but it's a bit messy in my head right now.
Thanks for any information !
They sent us 4 files and a password for the .P12 file: .csr, .cer,
.key, .P12
Ideally, you should have generated the private key (in .key) and CSR (in .csr) yourself and the CA should have come back with the certificate (typically in .cer) based on the CSR, which you would have assembled together to build your PKCS#12 file (.p12).
At this stage, you can discard the CSR. The PKCS#12 file should now contain the private key, its associated certificate and possibly the certificate chain attached. You could extract the .key and .cer files from that .p12 file later again. I guess you were given all these files because of the way they have been generated (using intermediate files), or for convenience, not to have to convert them yourself.
The Java terminology isn't ideal, but keystore and truststore are two entities of type keystore, but with a different purpose. The difference between the KeyManager and TrustManager (and thus between javax.net.ssl.keyStore and javax.net.ssl.trustStore) is as follows (quoted from the JSSE ref guide):
TrustManager: Determines whether the remote authentication credentials (and thus the connection) should be trusted.
KeyManager: Determines which authentication credentials to send to the remote host.
The javax.net.ssl.trustStore* properties are one way of configuring the TrustManager. The javax.net.ssl.keyStore* properties are one way of configuring the KeyManager.
Typically, there is no need for private key material in a trust store (unless you also use the same as a keystore). It's often better to use a separate truststore, which you'd be able to copy freely across machine, without worrying about leaking private key material.
What would make sense would be to build a new keystore (JKS) that you would use as a truststore, using the CA certificates (not sure if you've been provided with them).
You're not doing mutual authentication by setting the truststore only (there are no default values for the keystore, so they need to specify these parameters explicitly). If you want to use your client-certificate to connect to a remote party, you need to set it in the keystore (for example, using the javax.net.ssl.keyStore* properties in the same way you've done it for the trust store).
You could point both the keystore and truststore to the same .p12 file. The side effect is that other connections made by your service to other places (e.g https://www.google.com) would not be trusted, since it wouldn't contain the CA for those. That's why it might be better to create a separate "truststore keystore" (JKS might be easier) for the CA certificates. You could make a copy of the default cacerts (in the JRE directory), import your CA's certificate into it and use that.
I've got an application that is supposed to communicate with another
one using webservices and SSL.
Ok, stop here. Communicate how? I mean is it only server authentication i.e. your client application will authenticate the web service or mutual authentication and the web service will also request your applications certificate?
This is important as the files you present by the names seem to suggest the latter i.e. that mutual authentication is expected while your code you show is only setting SSL library for server authentication.
Since you are not providing context here I would say that:
.key has your private key
.p12 has your private key along with your signed certificate or perhaps the CA's root certificate (?)
cer could have your signed certificate or perhaps the root's CA
signing certificate that is considered as trusted in the domain and
has probably also signed the web service you want to communicate with
certificate (well that is a possibility/guess here since you don't
say much)
csr is your certificate signing request
I did a small Java class that call a webservices on this server, using
What you do in the code is setting the p12 as the truststore.
If you say this works then there is no mutual authentication only server side authentication and you are authenticating the web service using whatever is in the p12.
In this case the rest are not needed for communication.It is for you to keep especially the key file since this could be your private key and if you lose/someone steals this then your private certificate is useless/compromised.
I am not sure what your requirements on security are here, but it seems to me that you should probably look into it more.
Even for this question I just tried to do an educated guess based on the file names.....
I hope this puts you in some track to read.
Can we load multiple Certificates & Keys in a Key Store?
Is it always required to load only Pairs (i.e. Certificates & Keys together)?
If a Key Store has multiple Certificates and Keys, which one will get selected when Java SSL tries to establish connection as a Server?
Although this depends on the KeyStore type, generally, you can store multiple private keys and certificates in a single store.
Which key and certificate combination is used for a Java-based server will depend on how the application was implemented. A number of applications let you select a given certificate using the alias name. The key and certificate getters in KeyStore take an alias parameter to make this choice. Usually, when this is not specified in the configuration, the application or framework will use the first suitable one it finds based on the KeyStore.aliases() enumeration.
Tomcat, for example, uses the keyAlias attribute in its Connector configuration:
keyAlias: The alias used to for the server
certificate in the keystore. If not
specified the first key read in the
keystore will be used.
Regarding key pairs, some KeyStores (again, depending on the type) can be used to store SecretKeys (e.g. DES), that is shared keys, as well as public-private key pairs.
You can have a keystore with as many certificates and keys as you like.
If there are multiple certificates in a keystore a client uses as its truststore, all certificates are being looked at until one is found that fits. You can look at the preinstalled certificates, they are in /lib/security/cacerts. It's just a big collection of root CAs' certificates.
Regarding the keys I don't know. I'd reckon the client uses a key that is signed by the same CA as the certificate that is provided by the server and if there are multiple, the first is used. But I can't say that for sure.