I have a keystore of JKS type.
The client public/private key pairs are on it.The certs are not self signed.
If I view the public key entry in the keystore explorer it doesn't show the certificate chain. But if I extract the public certificate and view it outside of the keystore explorer it shows the certificate chain.
How do I add the certificate chain to show on the keystore explorer for the public certificate . I have the intermediate and root trusted certificates separately with me. I also don't have the password the private key.
Related
I am trying to understand how a self-signed certificate created by ROOT CA, can be used to validate (decrypt) a certificate signed by the private key used by ssCA.
I currently dont need an external CA, so i decided to use my own self signed Root CA, to sign other certificates.
Self Signed Certificate by Root CA is created using a private key (root.key). The certificate contains the public key of Root CA and some meta info.
Now if i use the root.key to sign another certificate C, how does the C can be validated by the self signed certificate of Root CA? (Isnt the self-signed certificate of Root CA encrypted by the root.key itself, and it has its public key as part of the signature. How will that signature be decrypted to obtain the exact public key?)
Isn't the self-signed certificate of Root CA encrypted by the root.key itself, and it has its public key as part of the signature
Signing and encrypting are orthogonal, i.e. data can be signed but not encrypted, they can be encrypted but not signed or they can be both signed and encrypted.
A certificate is signed, not encrypted.
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.
The company signs it own certificates so this is giving problems to validate so I have added the custom ca authority to a pod running jenkins so now I can curl successfully against a service, the thing is that I'm trying to use a jenkins' plugin which continue to give ssl error so I think the problem is that I need to add the certs in jks format but all the info I found to convert a pem to jks is with the private key which I don't have.
The plugin which I need to make work is micro focus fortify plugin.
How do I convert a public ca authority to jks if I don't have the private key?
I'm guessing you're just trying to add your internal CA cert to the cacerts file that you Jenkins server is using. The cacerts file is a keystore file that contains all of the public certs for trusted CAs and it will be located with the java installation that your Jenkins server is using.
Please note that if you're trying to trust other certs that were signed by your CA, then you only need your CA's public certificate. You do not require the CA's private cert. If you have an admin who gives out the private cert/key to anyone, you should probably slap that person because that is a major security risk.
When Jenkins starts up, it will use the public CA certs from that cacerts file which will also be used by any Jenkins plugins that you use.
To import a new CA cert, you just need the cert to be in base64 format. You can use the following command to import:
keytool -importcert -file yourCAcert.pem -keystore cacerts -alias "YourCertAlias"
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.
I am new to Cryptogrphy, HTTPS and SSL !!!
If i am not wrong , the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client !
But does a root certificate also have a Private Key?
If Yes, then I wanted to know where exactly the private key of a root certificate is used?
What happens if it is leaked ?
If I am not wrong, the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client
You are wrong. It isn't. The peer's own private key is used to sign the certificate so the client can verify that the peer owns the certificate he presents, and the private key of signing certificates is used to, err, sign certificates.
The root certificate's private key is (normally) only used to sign the intermediate certificates. Compromising it allows you to create new intermediate certificates, and by extension, certificates for any domain.
A root certificate is the top-most certificate of the tree, the private key of which is used to "sign" other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate - a signature by a root certificate is somewhat analogous to "notarizing" an identity in the physical world. If you knew the private key, you could create new (counterfeit) certificates.