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?
Related
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
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.
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
Is it possible to regenerate a private key in a .JKS keystore using keytool or equivalent?
I've been supplied with a certificate and a JKS keystore, but on importing the cert it looks like the private key that was used to generate the CSR has been deleted.
I can see how to create a new keystore with a new private key, but this won't then match the CSR or certificate.
No, that's the whole point of asymmetric cryptography: making it impossible to produce the private key when knowing only the public key (which is contained in the CSR and in the certificate).
If you could re-generate the private key only from the CSR or the certificate, anyone could impersonate the entity to which the certificate has been issued.
If you've lost your private key, you'll simply have to create a new key-pair, submit a new CSR and get a new certificate. Some CAs allow this sort of re-keying for free as part of their contract within the duration of the initial certificate.
EDIT: Just to clarify what a CSR is.
To apply for an X.509 certificate, you must:
Generate a public/private key pair. By nature, the public key can be publicly distributed, because it's not sufficient to obtain the private key (at least not in a reasonable time).
Submit that public key with your identity information to the Certification Authority. This can be done using:
A Certificate Signing Request (CSR, PKCS#10), which contains your public key and the data you would like to be in the certificate (e.g. the Subject DN you want). Although very similar to the data in a certificate, this data should mainly be used by the CA for identifying the request itself, since CAs doing their job properly should check what they put in the certificate, not just turn the CSR into a certificate blindly. The CSR itself is signed using the private key matching the public key in the certificate. It's effectively very similar to a self-signed X.509 certificate (without Issuer information and validity dates), but isn't one.
SPKAC or CRMF for in-browser certificate applications.
The CA then takes this CSR (or equivalent) and makes the necessary verification outside this process to vet the pieces of information it wants to embed in your certificate, and issues your certificate (by signing it with its own private key). It's effectively vouching for the binding between your public key (extracted from the CSR) and the information it embeds in the certificate (e.g. your name and/or the domain name for which this cert is). It sends you back this certificate.
You then have to use this certificate in conjunction with the private key matching its public key. Some tools do this using separate files, it's also possible to import the cert back against the private key entry in a keystore.
Having the CSR or the cert without the private key is of no use. You can quite easily create a new CSR again, but you'll also need to create a new key pair. The most important part of the CSR is the public key, and to have the matching private key. You can discard the CSR otherwise.
Is it possible to regenerate a private key in a .JKS keystore using keytool or equivalent?
Yes, but regenerate the private key and CSR. The CSR is submitted to the CA where you are provided a new public key.
You can reimport to the keystore anytime using the following command:
keytool.exe" -import -keystore "%JAVA_HOME%\jre\lib\security\cacerts" -file .\certificate.cer
Make sure you also import the certificate to both paths for the newer JDK releases:
C:\Program Files\Java\jdk1.6.0_31
The newer releases also deploy a separate JRE:
C:\Program Files\Java\jre6
Failure to do so may result in the following exceptions in log:
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
To regenerate your private key and CSR, you can use the following command:
$ openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out signing request.csr -config openssl.conf
I had the same trouble (my private key was accidentally deleted from keystore) and there was just one way to recover it: replacing the keystore file (*.jks) with a backup. So I recommend to always make backup with all files related to SSL, and if you delete anything by mistake on keystore just replace the file with an older one.
I am trying sign an app using keytool, but I dont have a keystore file.
Do I need to generate this file myself or should I receive it from from code signing authority ?
If so what files do I require to generate a keystore file ?
Thanks
The key store is a database for your keys. The process of "signing" an app (e.g. with jarsigner) is roughly the following:
You create a private/public key pair with keytool.
You then create a CSR (certificate signing request)
A CA (certification authority) processes your request and gives you a certificate.
You have to import the CA response into your keystore.
You may create self signed certificate to get a feeling of the process. You may use openssl.
You have the answer under your fingertips... keytool is your friend...
http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html
Keystore Creation
A keystore is created whenever you use a -genkey, -import, or -identitydb command to add data to a keystore that doesn't yet exist.
More specifically, if you specify, in the -keystore option, a keystore that doesn't yet exist, that keystore will be created.
If you don't specify a -keystore option, the default keystore is a file named .keystore in your home directory. If that file does not yet exist, it will be created.