understand ssl files and mechanisme [closed] - java
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
hello I'd like to have someone explain me how ssl works and most importantly explaine me what are all these file extension and what are their purposes for exemple I'm trying to connect to a kafka and i had a scrip that did an extract of secrets in mu kubernetes cluster for my kafka , and I got multiple files and don't know what tey're used for : so if someon can explaine me what is .trustore .keystore .pem .p12 .key .crt .ca.crt ... thank you I know that it might be vague but I'm new to using ssl and kafka so It would really help me if someone has some basic explanation of this .
Thank you for your help
This is a very complex topic and you should use Google. I'll try to answer here, but if you don't understand SSL, PKI and asymmetric encryption concepts you'll probably get lost in my explanation. You can find videos on Youtube and plenty of tutorial and explanations around internet.
Each SSL certificate is made from two parts:
SSL certificate itself - this is a public part, it contains Common Name, some other important information about certificate and its owner. Most important part is probably the PUBLIC KEY and CA signature
Private key - this is essentially the password - it is a private part and you must never share it with anyone
Private and Public keys are mathematically bound each to other. What you encrypt with one key can be decrypted with another key. Who has PRIVATE key can easily derive PUBLIC key from it but it doesn't work another way around. This is principle of asymmetric encryption.
The certificate and key are just two files. The extension doesn't really matter. But for convenience .key suffix is used for the private key. For certificate, we commonly use .crt, .pem or .der.
The important thing is how the certificate and private key is ENCODED. It can be PEM-encoded or DER-encoded:
PEM: this is human readable format. You can tell the PEM encoded certificate because first line contains -----BEGIN CERTIFICATE----- line.
DER: this is binary format. If you open this file in editor it will be bunch of non-readable nonsense as it's just bunch of 0s and 1s
Now you can see where suffixes .der and .pem come from. .crt suffix is used just as an alternative to .pem suffix. So that everyone can tell 'this most likely the certificate'.
The important part about the every certificate is that it must be signed by someone. The someone is Certification Authority. Certification Authority is just another public/private key pair. It's owned by some organization that's highly trusted. Certification authority can use their private key to sign your certificate. Their private key is super secure. What you can get to is the public key and this is what ca.crt, ca.pem or ca.der contains. The important part is that you can use CA public key in order to verify the signature done by their private key. The signature is part of your certificate.
There are publicly trusted certification authorities out there in the internet and every web browser trusts them. Those are organizations that are audited and commonly trusted.
You can create Certification Authority certificate and private key by yourself. Problem is nobody will trust it when you use it to sign the certificate. This is why you must take ca.crt file and provide it as well. Together with your server certificate whatever.crt you must also send ca.crt and tell the person who's trying to verify it 'hey! this is the CA I used to sign that certificate please trust it'. And it's up to them to trust it or not :)
Now .p12 extension. This is yet another form of the certificate. PKCS#12 is a certificate 'container' or 'archive'. You can put your private key file (.key) your certificate file (.crt, .pem or .der file) and "put" them together to one file. You can think of it as ZIP archive but obviously it's not ZIP file. You can protect it with password too. You can use openssl utility to create pkcs#12 container.
truststore and keystore are Java concepts. I personally hate them because they just overcomplicate things and don't add any value. Majority of Java applications can work with pem/crt/key/p12/der files. Kafka recently also included support but it's sort of half baked I'd say.
truststore is also 'archive' or 'container' that contains the 'certificates to trust'. In other words it contains Certification Authority files (one or multiple). So ca.crt file goes there (not its private key! just the ca.crt). It can contain multiple certificates. When Java application starts up it will read the file and will trust any certificate signed by certification authorities inside the file (for example when you connect from that java to some SSL protected webpage or server). Truststore is usually protected by a password.
keystore is also 'archive' or 'container'. You create keystore from .p12 archive. So the keystore contains same things as .p12 file. The certificate + its private key. Keystore is usually protected by a password.
keystore and truststore are created using Java keytool utility. And as mentioned you need .p12 file to create them so usual process is:
I will use openssl to generate private key
I will use openssl to generate CSR (.csr suffix) or certificate signing request file - this file is unsigned certificate
I will send .csr file to Certification Authority, they will sign it and provide back .crt or .pem or .der file (or even all of them so I can pick). They will also send you ca.crt file.
I will use openssl to put .crt and .key file to .p12 archive
I will use keytool to put .p12 archive to keystore archive.
I will use keytool to put ca.crt file to truststore archive
The majority of applications (I'm not sure if Kafka but for example Elasticsearch) that support SSL have some built-in tooling to help you set up your own certification authority and certificates for development/testing purposes. They are not meant for production but I think plenty of people use them that way.anyway.
Related
How can I validate certificate chain when CA certs held in Java Key Store
Can someone please help me with the following, I googled before hand but did not find a blog outlining what I wanted to do, thanks in advance. I have and internal test PKI (based on AD CS). I have imported the Root CA certificate and the Issuing CA Certificate (minus their private keys) into the CACerts java key store (keying the GUI tool "KeyStore Explorer 5.5.1" I have a leaf (end-entity certificate) 'outside of the Java keystore' as I want to simulate a situation where the client would obtain (be given) the leaf certificate via a WEB browser (for example when opening a TLS connection to a WEB server). The leaf certificate is stored in a .pem flat file on the same computer where it was create (using Windows default method so private key for the cert is in the Windows keyStore). The computer also contains the Java KeyStore CACerts (where I imported the CA certs as above) and the Java JDK (so Keytool.exe for example) So what I need to do (ideally using Keytool or a pre-made script suitable for Windows) is point to the leaf .pem certificate and say go check the certificate chain of this leaf certificate but using the CA certs held in CACerts keystore Can someone kindly tell me how to do this as the only examples I have seen this far are about checking the chain for certs already in the CACerts keystore. Whereas I want to check the chain of a .pem flat file against the CA certs held in the CACerts java keystore
Should certificates be always imported in keystores?
I'm doing some crytography in Java and I wanted to know what are the best and common pratices on certificate storage. Can certificates be loaded from a file or should they always be imported in keystore/truststore ? EDIT: My use case is to load a private key and a certificate in order to be able to crypt and decrypt data. The question is: should the private key and the certificate be both in a keystore or can the certificate be aside in a file ?
I'd strongly recommend storing the certificates at least in the key store. If your key store and file have about the same access rights security is not that much different - although the password does add a level of protection (it's not called "changeit" by default for nothing). Java and Java key stores are however pretty focused on X.509 based PKI, and you may not be even store the private key successfully without the certificate. So it is certainly best practice to store the certificate or rather, the certificate chain in the key store.
How to sign a Jar with a Godaddy Cert Pem file?
I have a java applet that needed signing, so I went with GoDaddy and bought a code signing certificate. I followed this tutorial I created a keystore and a CSR. And GoDaddy replied with the PEM file. This is where I am getting confused. According to the tutorial, I should have a PKCS#7 for step 3. This is not a PEM file. I have examined the PEM file in KeyStore Explorer and it seems to have the public and private key attached to it. I followed this stack thread, and still could not get it working. The error is: jarsigner: Certificate chain not found for: podScan. podScan must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain. This error appeared when I did the last step of Howard's post. Any thoughts on what to do?
When to install keystore & when to install only certificate wrapped in keystore [duplicate]
This question already has answers here: Truststore and Keystore Definitions (7 answers) Closed 6 years ago. I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry. In Android, I see people programmatically install keystore in the following way (The code is from Android developer blog): byte[] keystore = . . (read from a PKCS#12 keystore) Intent installIntent = KeyChain.createInstallIntent(); installIntent.putExtra(KeyChain.EXTRA_PKCS12, keystore); startActivityForResult(installIntent, INSTALL_KEYSTORE_CODE); I also see people programmatically install only the certificate wrapped inside keystore: Intent intent = KeyChain.createInstallIntent(); intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert); startActivity(intent); Besides, I also see people install both the keystore & the certificate wrapped in keystore. For example, this article shows us how to first install keystore & then install the certificate wrapped in keystore programmatically. I really get confused about when should I install keystore only & when should I install certificate (wrapped inside keystore) only ? And when should I install both ?? Could someone make me clear about this please? For example, my keystore PKCS#12 file (mycert.p12) contains key/certificate pair, it is used to connect to VPN server. When should my android client install both keystore and certificate wrapped in the keystore ? When should client install only certificate wrapped in keystore? What are the differences ? I am quite confused about this.
I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry. Correct. In Android, I see people programmatically install keystore in the following way ... This is done when you have a keystore, i.e. a keypair and certificate. I also see people programmatically install only the certificate wrapped inside keystore This is done when you have someone else's certificate, typically a self-signed one, that isn't trusted by any of the default CA's (certificate authorities) that are already installed. You should never have to do this. So note that you never do both with the same certificate, because the cases (the ownerships) are different. There can never be any doubt about which process is appropriate. If it's yours, import the keystore. If it's someone else's, import the certificate. The ultimate normative reference for all this stuff is ITU Recommendation X.509. Finally, some notes on the poor quality blog articles you have linked. From Unifying key store access in ICS: In the past, it was common practice for apps to maintain their own key store if they needed to authenticate a secure SSL web server, or authenticate the user to a server via a client certificate. This is already incorrect. To authenticate a web server you shouldn't need anything, if it has a CA-signed certificate. If it has a self-signed certificate you will need to import it into your truststore. To authenticate yourself to a web server, you need a keystore containing your own private key and a certificate, preferably a CA-signed one. Otherwise the server has to import your self-signed certificate into its truststore, i.e. the converse of (1) above. Don't go down this path. Self-signed certificates are far more trouble than they are worth, which is nothing, as you can tell from the price you pay for them. From Using ICS keychain API: We first get the private key and certificate chain using the key alias and then create and verify a signature to check if the key is actually usable. Complete nonsense. We already have the private key, the public key, and the certificate. They are already usable. Creating a signature and verifying it locally is just a complete waste of time. Installing a CA certificate is not very different from installing a PKCS#12 file: you load the certificate in a byte array and pass it as an extra to the install intent. The difference being that you use KeyChain.EXTRA_CERTIFICATE in the CA certificate case, and KeyChain.EXTRA_PKCS12 in the keystore case.
Since no one has answered you yet, I hope I can at least clarify some points from the blog article you have linked to. In the past, it was common practice for apps to maintain their own key store if they needed to authenticate a secure SSL web server, or authenticate the user to a server via a client certificate. These are the two basic use-cases right here: If you are authenticating with a client certificate (which proves to the server that you are an authorized client), then you would only install a certificate. If you are trying to verify the server's identity, then you will want to validate the server's certificate. In this case you will need a keystore installed (possibly a chain if you're not using self-signed certs). The private key in the keystore will be used to validate the server's certificate. That second bit of code you have in your question was intended for creating a certificate chain (when you're NOT using self-signed certs): We first get the private key and certificate chain using the key alias and then create and verify a signature to check if the key is actually usable. Since we are using a self-signed certificate the 'chain' consists of a single entry, but for a certificate signed by a CA you will need to find the actual end entity certificate in the returned array. Installing a CA certificate is not very different from installing a PKCS#12 file: you load the certificate in a byte array and pass it as an extra to the install intent. Intent intent = KeyChain.createInstallIntent(); intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert); startActivity(intent); I hope this explanation helps! :)
With respect to an android or any other 'client', that is, an application, the following hold - A truststore (public key only) is required whenever it needs to validate the certificate (or a certificate chain) that is sent across by the server during SSL communication (in case of ssl communication the server will always present its certificate to the client). If the server's certificate is already signed by a trusted certificate authority (implying that certificate is already present in the java-runtime-truststore that can usually be found under $JAVA_HOME/jre/lib/security/cacerts), then this step is not required unless a customized SSLContext is being used (which also means that a customized TrustManager is being used). For example SO's current certificate is signed by DigiCert identified by SHA1-Thumbprint : 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25 and would likely be present in the 'cacerts' truststore under the alias 'digicerthighassuranceevrootca'. If a java client were to make a request to https://stackoverflow.com then by default there would not be any specific keystore or truststore required for communication. A keystore (private and public key) is generally required when the client is required to digitally-sign some data which is being posting to the server. A common example is xml-signing, you can find a mention here It is also required if the server expects the client to present its own certificate for authentication as part of two-way ssl handshake. From what I have come across this is not common. Links : Two Way SSL SO's own Keystore and truststore post
Java Code Signing Without Private/Public Keys
How do I go about signing jar files if the private/public keys and CSR were generated on somebody else's computer? I have the certificate but what I am trying to understand is can the certificate only be used to sign jar files on the computer that the CSR was generated on or do I need to get that person to send me the private/public keys?
PKI Signatures are created by yourself with your private key and checked by others with your public key . Trust is established when (a) the signature is valid and matches the certificate that signed it and (b) the entity checking the signature either trusts your certificate directly or trusts the entity that signed it, the CA. The CSR is of no interest in this process and other peoples certificates are not used. Hope that clears it up.