No subject alternative names matching IP address with Strimzi - kubernetes

I have configured a Kafka Cluster with Strimzi. I have enabled tls authentication and I have exposed the service with NodePort.
After that I have exported my ca and my password to generate a JKS to connect with Kafka. But the problem is that I'm having the next error:
java.security.cert.CertificateException: No subject alternative names
matching IP address 172.26.195.44 found
To export password and ca:
kubectl get secret kafka-cluster-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.crt
kubectl get secret kafka-cluster-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 --decode > ca.password
To generate the jks I have made these steps:
keytool -genkey -alias kafka -keyalg RSA -keystore kafka.jks -keysize 2048
keytool -importkeystore -srckeystore kafka.jks -destkeystore kafka.jks -deststoretype pkcs12
export CERT_FILE_PATH=ca.crt
export CERT_PASSWORD_FILE_PATH=ca.password
export KEYSTORE_LOCATION=kafka.jks
export PASSWORD=`cat $CERT_PASSWORD_FILE_PATH`
export CA_CERT_ALIAS=strimzi-kafka-cert
sudo keytool -importcert -alias $CA_CERT_ALIAS -file $CERT_FILE_PATH -keystore $KEYSTORE_LOCATION -keypass $PASSWORD
sudo keytool -list -alias $CA_CERT_ALIAS -keystore $KEYSTORE_LOCATION
Also I have tried adding -ext SAN=dns:test.abc.com,ip:172.26.195.44
Any idea about this?

As described in the docs, when using node ports listeners, you have to by default disable the hostname verification in your client. The reason is that the node address is not known upfront to add it to the certificates and including all nodes would often not work because the worker nodes might come and go.
If you know the node addresses upfront because of your cluster configuration, you can have them added to the certificates using the alternativeNames option in the Kafka CR.

Related

How to find the keystore location and renew certificates using keytool

How to find the existing certificates on my computer using the keytools command?
I have to take a copy of the existing certificates for renewal and run the following commands
on the certs:
keytool -list -alias <<your cert's alias>> -keystore.<<your .jks file>> -storepass <>
I am not sure how to go about figuring the certificates on my system and are these certificates
related to Java/Linux or something else?
Separately where do I found keystore? Once I have the keystore location I could
use the keytool list -v command on the keystore to get the serial number of the certificate

kafka truststore file not found

I am trying to create and use a local kafka keystore.
I have created a trust store at repository_name/kafka/truststore.jks
I have config
props["ssl.truststore.location"] = "classpath:kafka/truststore.jks"
props["ssl.truststore.password"] = "password"
but when i boot up the app I get the kafka error
java.nio.file.NoSuchFileException: classpath:kafka/truststore.jks at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)...
This is a problem with the pathing I have used as I tried the absolute path and got no error. This however is not a solution as it is a shared repo, the path must be from the repo not absolute. I did try some alternate pathing such as kafka/truststore.jks which did not work.
The command used to create the keystore was
keytool -keystore truststore.jks -genkey -alias ts

IB CP WebAPI Gateway certificate change

I am trying to replace the default certificate for Interactive Brokers Client Portal WebAPI Gateway application. I am trying to install and configure the software on Windows 10 (20H2, build: 19042.685)
Here are the steps I followed:
Installed Java 8 Update 271
Downloaded the latest Gateway software, from here.
Unzipped the file to $HOME\Documents\clientportal.gw
Created the jks file using the following command:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore2.jks -storepass password -validity 360 -keysize 2048
Provided the details: CN=localhost, OU=home, O=home, L=riga, ST=riga, C=lv
Then exported the cer file using the following command:
keytool -export -alias selfsigned -file mydomain2.cer -keystore keystore.jks
Imported the cer file into following Local Machine certificate stores:
7.1 Trusted Root Certification store
7.2 Trusted Publishers store
7.3 Personal store
Ran the command as per the vendor: bin\run.bat root\conf.yaml
Unfortunately I still get the certificate error:
Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID
Any suggestions?
Thanks!

Configuring SSL on glassfish-4

Am trying to configure glassfish-4 for SSL but it seems i can't get it to work. By default glassfish uses port 8181 for SSL which of course works very well from my localhost prompting the browser to add the certificate in its truststore but from remote this fails with the exception -- SSL received a record that exceeded the maximum permissible length-- on mozilla firefox. I also tried generating my own key/pair using java's keytool in the config folder of the domain1, I then changed certificate nickname on glassfish to the alias of the new keystore but this fails to work instead returns the default certificate from alias s1as even after restarting the server. Below is the command i used to generate the keystore file.
keytool -genkey -alias MY_ALIAS_NAME -validity 1000 -keyalg RSA -keysize 1024 -keystore /opt/......./domain1/config/keystore.jks
The first and last names being the IP address of the remote when generating it. Please help, thanks.

Unable to authenticate to Intuit API Explorer

I am attempting to authenticate to the Intuit API Explorer to become better acquainted with the Customer Data (AggCat) API.
I enter the Consumer Key/Secret, SAML id, user ID, and the original .crt certificate that I uploaded. I get the error:
The given certificate file is not supported. Please provide valid PEM certificate file.
I don't understand this error, because the .crt file is PEM-encoded, as far as I can tell.
Nevertheless, I went to the 'Create X.509 keys' page:
http://docs.developer.intuit.com/0020_Aggregation_Categorization_Apps/009_Using_AggCat/0010_GettingStarted/0015_Create_an_AggCat_integration/0010_Creating_X.509_Public_Certificates
and followed the instructions at the bottom 'Generating a PEM file'. I am able to get past step 1. (convert jks store to p12 format), but I get the following error when attempting to run step2:
$ openssl pkcs12 -in keystore.p12 -nocerts -out cert.pem
MAC verified OK
Error outputting keys and certificates
139679448614560:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
139679448614560:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:p12_decr.c:104:
139679448614560:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:130:
I am using jdk-1.7.0_17 and openssl-1.0.1 on ubuntu-12.04 LTS.
Thanks for any help.
Found it, stop looking!
The problem arises from the fact that the PKCS12 format does not support separate passwords for the storage file and any keys inside it. Both the storage file and the key inside it have to be encrypted with the same password.
So the easiest was to go through the process again, and in the step of generating the initial private key and keystore with keytool:
keytool -genkey -alias myapp -validity 1095 -keyalg RSA -keystore keystore.jks
make sure to use the same password for both the keystore (storepass) and the private key (keypass).
As an alternative, if you really must/want to use separate passwords for the keystore and key in that step, in the initial step for creating the PEM:
keytool -importkeystore -srckeystore [MY_KEYSTORE.jks]
-destkeystore [MY_FILE.p12]
-deststoretype PKCS12
-deststorepass [PASSWORD_PKCS12] change this to [KEYPASS]
-srcstorepass [PASSWORD_JKS]
set the -srcstorepass to the password of the keystore (storepass), but set the
-deststorepass of the PKCS12 file to the password of the private key (keypass) used when creating the key/keystore via the keytool -genkey command further above.
I have not tested this alternative, but it should work as well, since both the PCKS12 store and the key would end up using the same password.