I want to hit the REST endpoints of a Server, say xyz.com. They have provided certificates in PEM format which I should be including in my application while connecting to their endpoints.
My application is written on Spring Framework and I need to convert PEM to P12 format as Spring won't accept PEM. This is how I convert:
openssl pkcs12 -export -out certificate.p12 -inkey private.pem -in server_cert.pem
Where,
certificate.p12 = resultant p12 file
private.pem = private key
server_cert.pem = certificate files of the server
The error I get is:
No certificate matches private key.
Now my questions:
Whose private key should be used to generate the P12 file from the PEM file?
If the private key of client is used to generate p12, how could it possibly match with the certificate (error message becomes obvious)?
Why would I need my private key to communicate with the server? As per my understanding, during an SSL session, the private key of the client doesn't come into the picture. Or is my understanding wrong?
If the private key of the server is used to generate p12, why would they share it?
I'm a novice and therefore any links/suggested-reading/sources/answers are welcome.
If you look at how the client-authentication works, in the 'Negotiation Phase', the second from the last point says:
The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
So to answer your questions:
You should be using the private-key that was given to you.
A PKCS12 is a type of Java KeyStore, which is similar to a standard JKS. It can contain a list of keypair's. But the internet standard of PKCS12 is to have only 1 key pair entry, i.e., 1 Private Key with its associated certificate-chain. Since the private key and the certificate chain were given to you as separate entities, you should be constructing the PKCS12 yourself, which you will be using in your code, to authenticate your client to the server that is providing you the service.
If you look at the steps of how the handshake happens at the protocol level, you should see that the client's private key (your private key) is used to sign some data and send to the server, where the server will be validating the authenticity of the message based on your public key. Once the server validates the message, it will come to a conclusion that you posses the private key.
You wouldn't be given servers private key. You are given your (users) private key, which you guard it and shouldn't be giving to anyone.
There might be something missing or trivial error while you are constructing with p12 with the private key and the certificate chain, which is causing to fail. If it doesn't work out, you could also construct the p12 using the KeyStore api programmatically.
Related
PEM file from the server side which is in the following format when opened:
-----BEGIN CERTIFICATE-----
somestuff1234
-----END CERTIFICATE-----
I'm trying to convert this to get two JKS files (A trust store and key store) which I can call the server with using my java application through SSL.
Can anyone help in a easy break down on how to do this using openssl and then the java keystore? I tried following the instructions in: https://docs.oracle.com/cd/E35976_01/server.740/es_admin/src/tadm_ssl_convert_pem_to_jks.html
But I couldn't import the keystore successfully as for some reason it was empty. PS when following these instructions I created the PKSC12 from der without a private key inputted since I wasn't provided one.
Do I need to use my own private key which I need to create as well but not sure if it is needed since I was only given the certificate? I've been told intermediate certs are sent in the TLS handshake.
Thanks for any help on this.
Try to run your java code with debug mode and specific truststore regarding the SSL server like described here:
How to configure trustStore for javax.net.ssl.trustStore on windows?
If the only thing in that PEM file is what you've posted:
-----BEGIN CERTIFICATE-----
somestuff1234
-----END CERTIFICATE-----
you will not be able to create a full keystore suitable for use as a TLS server that accepts connections.
You need the private key corresponding to the certificate for that.
Do I need to use my own private key which I need to create as well but not sure if it is needed since I was only given the certificate?
No - along with its identifying data, your certificate has a public key in it. The entire certificate was cryptographically signed by your CA - which is how the "trust" is transferred to your certificate. The public key in your certificate was derived from a specific private key.
Why won't it work? Because data that's encrypted using the public key in your certificate can only be decrypted using the private key that public key was derived from.
Your certificate will only work if it's paired with the correct private key.
But:
I created the PKSC12 from der without a private key inputted since I wasn't provided one.
You must have a private key along with your certificate to be able to run a TLS server.*
EDIT:
And you must have the proper private key paired with your certificate to use it as a client certificate when connecting to a TLS server for the same reason.
Also, a TLS certificate is public - if it were all you needed to prove your identity, publicizing that would make it useless. Your possession of the appropriate private key is what proves that the certificate is your certificate and not mine or anyone else's.
Your TLS server or your client connection to a TLS server isn't going to work until you locate the proper private key for the certificate you have. If you or your organization have lost that private key, you have to create a new private key and go through the process of creating a new certificate from that new private key.
Because without the correct private key, the certificate you have now is utterly useless.
* - Technically not true. The TLS standard does support "anonymous" cipher suites that do not require any certificate or private key. But almost no application supports anonymous cipher suites. OpenSSL only supports anonymous cipher suites if you compile it from source yourself, for example.
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.
I have an HTTPS endpoint that requires a client certificate(mutual TLS).
I have created a keystore using KeyStore Explorer tool and inserted the client certificate and private key into it(entry has an alias, that is some random string).
Then I have attached that keystore to RestTemplate and my question is the following:
How the right entry(certificate) is picked up from keystore when the call is made to a particular endpoint ? What if I have multiple certificates inserted into keystore so that each of them should be picked up only in case when request is made to an appropriate endpoint(domain).
If you are maintaining multiple public private key entries in one keystore file, then in each connector of respective public keys you need to pass the value in java as "keytoreAlias" . This way the application can distinguish which certificate to Cal based on alias mentioned.
I've just receive a certificate, containing those files:
- Root CA Certificate - AddTrustExternalCARoot.crt
- Intermediate CA Certificate - USERTrustRSAAddTrustCA.crt
- Intermediate CA Certificate - SectigoRSADomainValidationSecureServerCA.crt
- Your PositiveSSL Certificate - www_guerrilla_app.crt
and also the PositiveSSL Certificate in text format.
I would like to know if it is possible to generete the Private Key from the command line, maybe using Java or other tool
No. If you could it would mean the entire https internet is broken. You need the key from whoever generated the CSR.
The proper workflow is: create a SSL key, generate a Certificate Signing Request (CSR) with that key, provide the CSR to the SSL Certificate provider (PositiveSSL), have them sign it and give you a certificate.
To add to what Kees answered - you will generate CSR and private key together. This private key you will required when add them to load balancer to nginx
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.