After I got certificate, I tried to import it as specified here: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File
But I got this error:
C:\Program Files (x86)\Java\jre6\bin>keytool -import -alias tomcat -keystore C:\ SSL\.keystore -file C:\SSL\SSL_Internal_Certificate_for_isdc-planning.cer
Enter keystore password:
keytool error: java.lang.Exception: Failed to establish chain from reply
I need to import first chain certificate, by apache document
Import the Chain Certificate into you keystore
keytool -import -alias root -keystore <your_keystore_filename> \
-trustcacerts -file <filename_of_the_chain_certificate>
When I printed the certificate it's issuer is:
Issuer: CN=Intranet Basic Issuing CA 2B
I downloaded the chain certificates:
Intranet Basic Issuing CA 1A(1).crt
Intranet Basic Issuing CA 1A(2).crt
Intranet Basic Issuing CA 1A.crt
Intranet Basic Issuing CA 1B(1).crt
Intranet Basic Issuing CA 1B(2).crt
Intranet Basic Issuing CA 1B.crt
Intranet Basic Issuing CA 2A(1).crt
Intranet Basic Issuing CA 2A.crt
Intranet Basic Issuing CA 2B(1).crt
Intranet Basic Issuing CA 2B.crt
Intranet Basic Policy CA(1).crt
Intranet Basic Policy CA.crt
Root CA.crt
Issuer of Intranet Basic Issuing CA 2B.crt is Intranet Basic Policy CA and its Issuer is:Root CA certificate
But I can't import 3 certificates into root alias.
And imported "Intranet Basic Issuing CA 2B.crt" into root and then rerun import of tomcat alias
But got the same error:
keytool error: java.lang.Exception: Failed to establish chain from reply
What is correct way to import correct chain certificate?
Related
I am trying to setup 2 way ssl authentication. My requirement is broker should authenticate only specific clients.
My organization has a CA which issue all certificates in pkcs12 format. steps i followed are as follows.
get a certificate for the broker and configured it in the broker keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
ssl.client.auth=required
get a certificate for the client and configured it in the client keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
extracted the public certificate from the client certificate using keytool command
keytool -export -file cert -keystore certificate.p12 -alias "12345" -storetype pkcs12 -storepass xxxxx
imported the certificate into broker truststore. broker truststore contains only the client 12345 certificate.
keytool -keystore truststore.p12 -import -file cert -alias 12345 -storetype pkcs12 -storepass xxxxx -noprompt
configured the truststore in the broker.
ssl.truststore.location=/home/kafka/truststore.p12
ssl.truststore.password=xxxxx
configured the truststore in client. client truststore contains CA certificates.
ssl.truststore.location=/etc/pki/java/cacerts
ssl.truststore.password=xxxxx
When i run the broker and client i expect the broker to authenticate the client and establish ssl connection. but instead following error is thrown.
[2021-06-03 23:32:06,864] ERROR [AdminClient clientId=adminclient-1] Connection to node -1 (abc.com/10.129.140.212:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2021-06-03 23:32:06,866] WARN [AdminClient clientId=adminclient-1] Metadata update failed due to authentication error (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLProtocolException: Unexpected handshake message: server_hello
I tried various things but nothing seems to work. when i replace the broker truststore with /etc/pki/java/cacerts truststore file which contains only the CA certificate
then it works fine. but it will authenticate any client which has certificate issued by the CA.
what could be the issue ?
The default format is jks,
use keytool to create a Java KeyStore (JKS) with the certificate and key for use by Kafka. You'll be prompted to create a new password for the resulting file as well as enter the password for the PKCS12 file from the previous step. Hang onto the new JKS password for use in configuration below.
$ keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12 -alias myserver.internal.net
Note: It's safe to ignore the following warning from keytool.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12"
Say I have the following certification chain
some_company
|______ some_company_technical
|_____________some_cert1
some_cert1 will be replaced every year. By importing the Root certificate and the Intermediate certificate into my client's truststore...
keytool -import -trustcacerts -alias some_company -file some_company.crt -keystore some_client.jks
keytool -import -trustcacerts -alias some_company_technical -file some_company_technical.crt -keystore some_client.jks
...will some_cert1 (and some_cert2, some_cert3 .... some_certn signed the same way) be recognized as a trusted certificates by my application or am I misunderstanding how truststore works ?
As long as the some_certx is signed by the same SubCA/CA, and if these CA certificates are trusted by the client, you should be good, meaning the some_certx will be recognized as trust certificate.
How and Why?
Clients (eg: browser) that communicate with secured servers see if the server's certificate is signed by a CA that the client trusts. If the server's certificate is signed by a CA that client doesn't know about, there is no chain of trust. In simple words, the client doesn't trust the organization (CA) that trusted the server. This is what chain of trust means, do I trust the organization that trusted you? If I trust the organization that trusted you, I can trust you.
You might be thinking what the role of the end-entity (some_certx) would be. The clients have their ways to check the validity and status (revoked or not) of the certificate. The data required for these checks can be found in the end-entity certificate itself. The validity of the certificate can be verified using the Valid from and Valid to fields, and the status of the certificate can be checked using CRL or OCSP. The URLs for these can be found in CRL Distribution Point or Authority Info Access extensions of the certificate.
If either of the 2 above conditions fail, the server cannot be trusted.
I am trying to test SSL with a spring boot app running on my personal computer. I generated a PKCS12 certificate using keytool with the following parameters.
CN = localhost:8080
OU = localhost:8080
O = localhost:8080
L = Galle
S = Galle
C = LK
I configured my app to use this certificate and installed this self signed certificate in to my chrome browser.
When I attempt to access my API endpoint (https://localhost:8080/api/meta/divisions) using the chrome extension Advanced REST client, I am receiving an error saying
Certificate is invalid for given domain
Certificate presented to the app has different CN (common name) than the domain of the request.
What is the reason for this error, how can I fox this?
This was fixed when using 127.0.0.1 as CN and filling a SAN extension when generating the self signed certificate.
I tried to reproduce the same behaviour and initially my chrome also blocked the page. It looks like google is not allowing localhost:8080 as CN name.
If you try the following command:
keytool -genkeypair -keyalg RSA -keysize 2048 -alias server -dname "CN=abcd,OU=efgh,O=ijkl,C=Galle" -ext "SAN:c=DNS:localhost,IP:127.0.0.1" -validity 3650 -keystore identity.jks -storepass secret -keypass secret -deststoretype pkcs12
Add the following spring properties to your application with your own values:
server:
port: 8443
ssl:
enabled: true
key-store: classpath:identity.jks
key-password: secret
key-store-password: secret
Export the certificate from the keystore and added to your machine or chrome and it should work. To extract the certificate you can use the following command:
keytool -exportcert -keystore identity.jks -storepass secret -alias server -rfc -file server.cer
Could you retry it with the steps above?
I have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
I am trying to configure Jenkins on Windows with a SLL certificate following these instructions. Instead of using a Digicert certificate, our IT administrator would like to generate a certificate using the Windows AD CS using the certificate snap-in of mmc.
However we cannot figure out how to import the keytool generated csr certificate request into the certificate snap-in.
If I use a certificate with a recreated certificate request in the mmc certificate store, the certificate is rejected with the following message:
keytool -importcert -alias jenkins -file "D:\Temp\jenkins\jenkins.pem" -keystore "D:\Temp\jenkins\jenkins.jks"
Enter keystore password:
keytool error: java.lang.Exception: Certificate reply does not contain public key for <jenkins>
Does anyone know how to create an SSL certificate from the Windows certificate store based on a java keytool created csr certificate request?
I was able to get Jenkins running with SSL and this is what I did.
On the Jenkins Master
In the Certificate Snap-in of mmc, navigate to Certificates (Local
Computer) / Personal.
Right click Personal Folder and select All Tasks / Request New
Certificate...
Confirm the next two Enrollment pages by clicking on Next.
Check a Webserver Active Directory Enrollment Policy.
A Warning Message shows below the Enrollment Policy
More information is required to enroll for this certificate. Click here
to configure settings.
Click on it.
Fill out the Certificate Properties: Subject name: Common name:
[the name of your jenkins server] Alternative name: DNS: [the
name of your jenkins server] Alternative name: DNS: [the full
name of your jenkins server including your domain]Confirm the
page with OK and the following two pages.
Export the Certificate as PFX format Right click on
certificate All Tasks / Export...
Check: Yes, export the private key Check Include all
certificates in the certification path if possible Check:
Export all extended properties Since we are exporting the
private key, we must provide a password Check: Password and
enter your password and password confirmation
Pick a path for your PFX certificate and finish the export.
Export the certificate one more time without a password in the
Base-64 encoded X.509 (.CER) format.
Rename the resulting .CER file into .PEM.
Create a java key store on the Jenkins server with
keytool -genkeypair -keysize 2048 -keyalg RSA -alias jenkins -keystore jenkins.jks
Answer the questions appropriate for your company and organisation.
Import the PFX certificate into the java keystore with
keytool -importkeystore -srckeystore jenkins.pfx -srcstoretype pkcs12 -destkeystore jenkins.jks -deststoretype JKS
Copy the jenkins.jks to secrets directory where Jenkins is
installed (in my case C:\Program Files (x86)\Jenkins\secrets).
Add the certificate to the Jenkins startup parameters:
-Djavax.net.ssl.trustStore=%JENKINS_HOME%\secrets\jenkins.jks
-Djavax.net.ssl.trustStorePassword=[your password for the java key store]
Restart the jenkins service
On the Jenkins Agent
Import the PEM certificate from above into the java keystore from the command line with administrator priviliges:
keytool -import -alias jenkins -keystore "C:\Program Files (x86)\Java\jre1.8.0_161\lib\security\cacerts" -file [your pem file]
Enter the password of the keystore (by
default changeit) Trust this certificate? [no]: yes
Make sure your jenkins-slave.xml in %JENKINS_HOME% does not contain
-noCheckCertificate in the arguments.
Restart the service jenkinsslave-D__Jenkins.
I am reading the tutorial you have mentioned in your post. And I see this sentence:
"if making your own certificate skip steps 3, 4, and 5". Your code seems to be the specified in step 5.
You could try to copy the keystore file to your Jenkins secrets directory as mentioned in step 6.
This link can also be helpful.