Normally a cacert is used as a truststore which means a base where we put certificates of other servers so that we will authenticate them (we trust connection from these servers only if they use the same certificate as in truststore).
Whereas, a keystore is normally used for storing keys (they are used when we behave as a servers).
But the problem is that I find in the internet commands for adding certificates too in keystore and that there's no basic functionality in keytool for adding a private key in keystore.
So, I start wondering if I did misunderstand the purpose of a keystore and it's role. Can anyone tell me if I'm wrong?
Technically a KeyStore and a TrustStore are of same type. They just serve different purposes based on what they contain.
A KeyStore is simply a database or repository or a collection of Certificates or Secret Keys or key pairs. When a KeyStore contains only certificates, you call it a TrustStore.
When you also have Private Keys associated with their corresponding Certificate chain (Key Pair or asymmetric keys), it is called a KeyStore.
There are different types of KeyStores the JCE provider supports:
JKS (Java Key Store) --> When you have only certifcates, it is a TrustStore. When you also have Private Keys associated with the certificate chain, it is a KeyStore.
JCEKS (Java Enhanced Key Store) --> These can store what JKS can store and additionally Secret Key (Symmetric Key) too. You cannot store secret keys in JKS type KeyStore's.
PKCS12 --> This is like a KeyStore but a different type called PKCS12. These can store Private Keys along with their certificate chains. But the standard is to have 1 Entry only, i.e, 1 Private Key and its associated certificate chain.
Their purposes can are broad, but generally used for these purposes:
JKS - Securing your web server.
JCEKS - Store your encryption keys (symmetric), can also be used to secure web server.
PKCS12 - When a web server is setup for Two-Way SSL, it requires the clients to authenticate to the server. In these cases, the client would generate a KeyPair, and generate a CSR (PKCS10) from it and have it signed by a Certificate Authority (CA). The client is then given a certificate chain, which the client associates it with his PrivateKey in a PKCS12 KeyStore. It can then be used to make the SSL connection.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I want to use SSL encryption and authentication, but we have many clients and we don't want to generate new keystore for each client, is it possible to use the same keystore for each clients and if yes what are the possible problem with this configuration.
Confluent say that you can't use the same keystore for each client. But you can use the same truststore for all.
https://docs.confluent.io/2.0.0/kafka/ssl.html#configuring-kafka-clients
Keystore is used to store private key and identity certificates that a specific program should present to both parties (server or client) for verification. Private key need not be shared only public key.
Truststore is used to store certificates from Certified Authorities (CA) that verify the certificate presented by the server in SSL connection
Can anybody clarify to me what kind of "Private Key" is located in a PFX file ?
I am asking this because after having read quite a lot on digital certification I am still a bit confuse on the Private Key part, especially when Certificate Authority is involved.
The part I am missing is where it is said that the Private Key is kept secret on the CA side but if I go in my Personal Certificate Store and I try to export a certificate, I am able to export it with the private key in it.
Is this private key is the same as THE private key that we are not supposed to know ?
Public key cryptography is used for two different purposes when it comes to X.509 certificates used for SSL/TLS.
Each X.509 certificate contains a public key, which has a matching private key held only by the identity this certificate belongs to (the subject of the certificate).
One of the purposes is to build trust in another certificate. A CA uses its private key to sign other certificates: possibly other (intermediate) CA certificates or End-Entity Certificates (the ones that are actually going to be used for the SSL/TLS connection itself).
For example, the Root CA's private key can be used to sign (i.e. issue) an Intermediate CA's certificate. The Intermediate CA certificate can be verified using the Root CA certificate's public key. The Intermediate CA's own key-pair isn't involved in this verification (although the verification process ensures that the public key in that cert belongs to the Intermediate CA).
The Intermediate CA's private key can be used to sign your server certificate (an EEC). The Intermediate CA's public key can be used to verify the authenticity of your server certificate. Someone who would only have the Root CA certificate can therefore check your server certificate by building a chain. Again, your server public and private keys are not involved in this verification at all, but the result of these operations proves that the public key in your server certificate belongs to your server name.
There is no relationship between any of the key pairs involved in a certification chain. Even the CA issuing a certificate will not (or should not) have access to the private key of the certificate it is issuing.
The second usage of public key cryptography is during the SSL/TLS handshake. The exact mechanism depends on the cipher suite, but this allows the client to agree with the server on a secret that only the server with the private key matching the public key in the server certificate will be able to see. It's this private key that is the private key of the certificate itself.
In a PKCS#12 file, you will find an End-Entity Certificate and the private key matching the public key in that certificate, to be used by the entity to which this certificate was issued, and generally a chain of CA certificates (from the one directly issuing the EEC to other CA certificate further up the chain, possibly up to a Root CA).
Here, I've taken this example of an EEC for an SSL/TLS server, but the same could apply for EEC to be used in other contexts (e.g SSL/TLS client or S/MIME).
If you are talking about SSL-Certificates and SSL I think you mean X509-Certificates in common. Let me make it clear first: the passwords of the private keys are different.
The magic here is Chaining of the Certificates, i.e.
Root Certificate from CA
Intermediate Certificate from CA (for instance Class 2)
Your Certificate
If you look at your SSL-Certificate, you will find this structure. Every certificate within this hierarchy can be seen as a certificate for its own. You can find more information within this msdn article. A briefly description from my point of view:
The Certifcates within this chain can be seen are separate Certificates. With their own ability to sign Information with the private key and validating signature with their private key. They are basically linked within this chain.
You might ask Why are the Certificates linked?
There are two main reasons: Security and Trust.
If you loose your private key or if your certificates is broken, it's need to be revocated. This basically says, that your Certificates should not be trusted anymore. It's listed on the Revocation-List on the parent Certificate to ensure that this security break can be fixed very fast. This behavior explains, why root certficates creating IntermediateCertificates and not your requested Certificate - they want to be sure that they can revocate their Intermediate Certificate as well.
Additionally to this functional explanation there is a mathematical, but I am not able to explain this is an easy way. You can find Information about this within it's article on Wikipedia. Basically it says, that you can't calculate the password from the parent and / or public certificate to use the private certificate.
I'm consuming a web service from an Android device using HTTP(s) with SSL. A self-signed (untrusted) certificate is used for client authentication.
I have a general understanding of how public/private keys are used for SSL. From my understanding I can clearly see how a certificate can be used to set up a secure connection and transmit data securely. However I do not understand how they are used for client authentication since the certificate contains the public key and is not kept a secret.
I have a few questions:
Where can I read about how SSL and certificates can be used for client authentication?
Even if the certificate was not made public...by visiting the HTTPS URL in a browser I can view and save the certificate. I can then package up the certificate in a key store and use it from an application.
In this post Jeremy Huiskamp writes
client auth will automatically be performed when the server requests
it
...so client authentication as well as encryption of data can be performed with certificates?
Edited to answer the first part of my question: The client keystore should contain not only the server's public key but also the client's private key. The server must then be able to decrypt using the client's public key? Does this mean the keystore should have two certificates?
First, a quick point about the terminology in public key cryptography:
you sign and decrypt/decipher using a private key,
you verify (a signature) and encrypt/encipher using a public key.
(You don't really "decrypt" using a public key.)
Using SSL/TLS with or without client-authentication, the server presents a certificate (*) for which it has the private key. The server sends its certificate during the SSL/TLS handshake (at the beginning of the connection) and is able to decipher what the client sends using its private key (which it keeps private). The private key and certificates are stored in the server's keystore (or equivalent if it's not implemented in Java).
As part of this, the client uses its truststore, which is a form a keystore that contains trusted certificates, to verify the server certificate. The server certificate could be trusted by being explicitly in the truststore or, in most cases, trusted by linking in to a trusted CA certificate in the truststore (PKI).
The terminology between keystore and truststore in Java can be a bit confusing, you can find more details in this answer.
Regarding your question, the client's truststore doesn't contain the server's public key, but either its certificate or a CA certificate with which it should be verifiable. (It's not just about having the public key, but knowing whose it is, using the other pieces of information in the certificate.)
When you use client-certificate authentication in addition to this, there is a truststore (or equivalent) on the server side and a keystore on the client side too, since the roles are reversed for this purpose.
In the SSL/TLS handshake that uses client-authentication, the server requests a certificate from the client, who sends it (if available).
At the end of this handshake, the client sends a CertificateVerify message, which signs all the messages exchanged so far between the client and the server (so it's something known to both) using the client certificate private key. The server is then able to verify this signature against the public key within the client certificate it has obtained as part of this exchange. This proves to the server that whoever is on the client side has the private key corresponding to the public key in the certificate it has sent.
The next step for the server is to verify whether to trust this certificate, i.e. whether to trust the binding between identity and public key as presented and "sealed" within the certificate.
This is usually done using a PKI, whereby you check the certificate against a known CA, or if your deployment environment is sufficiently small, against a fixed set of trusted certificates. (There can be alternative methods of verification, but their usability will really depend on the circumstances where you want to deploy this system.)
Therefore, for your second question:
The client keystore should contain at least the client's certificate and its private key.
The client truststore should contain the server certificate or a CA certificate with which the server certificate can be verified.
Since both keystore and truststore are a keystore (in the storage format sense, usually a file) used for a different purpose, it's often possible to use the same keystore to serve both the purpose of keystore and truststore.
(*) There are cipher suites that don't rely on certificates, but that's unusual and off topic for this question.
A certificate just binds an identity to a public key. This binding is not secret, so there is no need to keep the certificate secret. If I have John Smith's certificate, I can prove that John Smith owns the secret key corresponding to a particular public key. But since I don't know that secret key, the certificate is of no use to me.
When authentication occurs by certificate, one step is always to have whoever presents the certificate prove they know the secret key corresponding to the public key in the certificate. If you cannot pass that step, the authentication fails.
The server's keystore should have the server's certificate. The client's keystore should have the client's certificate. The client will present its certificate to the server, so the server will learn the client's public key that way. (And vice-versa.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can seeļ¼
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.