While configuring kafka security using ssl certificates, is it possible to have multiple certification authorities in kafka truststore .jks file ?
When i tried adding multiple CAs to truststore, only one CA can be added with the alias caroot. Looks like kafka supports only one CA at a time. if we can add multiple CAs please provide the steps
Related
Maybe I miss something, if so forgive my ignorance.
Here what we have:
We use TLS authentication listeners in Kafka cluster (this can be changed, we can add new type of listeners).
When connect to Kafka topic from Java code I use SSL certificate generated for the Kafka user.
If I decide to avoid using SSL certificate, because of 2 reasons:
I will connect to Kafka topic only from trusted OpenShift cluster PODs
To avoid updating on producer/consumer side re-generareated yearly user's SSL certificate (because Kafka generates user certificate 1 year valid period)
Would be the SCRAM-SHA-512 authentication type for KafkaUser a better (and the only ?) choice for the two reasons above? Or SCRAM-SHA-512 also requires SSL certificates?
Another approach I saw was no authentication, but I am not sure how can ACL be used for such users? How I pass to server information which user is connecting. Is it possible to use both ACL and not authenticated by SSL certificate or by password Kafka user?
[UPD] Environment is built on Strimzi (Apache Kafka cluster in OpenShift)
Using SCRAM-SHA-512 does not require TLS. So you can just disable the TLS encryption in the Kafka custom resource (.spec.kafka.listeners -> set tls: false), enable he SCRAM-SHA-512 authentication (same place, in the authentication section). And then you just use the KafkaUser to create the user and get the password.
In general, TLS encryption is normally always recommended. But the SCRAM-SHA mechanisms do not send the password over the network directly, so using it without encryption should not leak the password. At the end, it is up to you to decide.
Also, just as a sidenote - the certificates are for 1 year by default. You can change it in the Kafka CR.
Good day,
My web application need to connect to IBM third party to get some response. Thus, IBM give me a .p12 file which contain of client certificate.
At first I import this .p12 file into my existing CellDefaultKeyStore, and it will hit certificate chain error.
com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by xxx is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
Then I go import this .p12 file into NodeDefaultKeyStore, and surprisingly its work. My application able to call to the third party and get reponse code 200.
I am not understand how to explain to my client on this.
As my understanding, management scope in CellDefaultKeyStore is bigger because its in cell, NodeDefaultKeyStore should consider part of cell only, suppose CellDefaultKeyStore should work.
Anyone can advise on this?
Just to shortly explain few concepts:
CellDefaultTrustStore - is store for signer certificates, for the servers that you connect to, to be trusted. It is shared by all the nodes and servers by default
NodeDefaultKeyStore - is store for private certs, so the certs that are used for client authentication. Each node by default has its own store and private cert to authenticate.
CellDefaultKeyStore - is store for private certs associated with the cell. Used by deployment manager, not nodes serving apps. It is NOT used by federated nodes.
NodeDefaultSSLSettings - this manages SSL config for the given node, you can check it. By default it is using NodeDefaultKeyStore (not CellDefaultKeyStore), and CellDefaultTrustStore
But back to your question.
If you need to connect to some service using client certificate authentication, what you should do is:
create new keystore with cert from the p12 file
create new truststore with all signer certs required to connect to that service
create new SSL Config that will point to these stores
create Dynamic outbound endpoint SSL configuration settings, pointing to your ssl config, select correct client cert, and specify connection info in the form protocol,host,port
This configuration will be picked up when you will be doing outbound ssl connection that matches info you entered.
I use ssl keystores for Jetty 9 and Kafka. I need to provide keystore and key passwords to access the keystore and private key. However, I don't want to provide these passwords in clear text in the configuration files. What other options are there to securely provide/encrypt the passwords? what is the pros and cons of each approach?
Since Kafka 2.0.0, all password configs can be preloaded in zookeeper before you start brokers. The kafka-configs.sh tool can be used to store passwords in an encrypted format in Zookeeper avoiding the need to specify them in plaintext in the properties file.
See the Updating Broker Configs section in the Kafka docs, especially the "Updating Password Configs in ZooKeeper Before Starting Brokers" paragraph.
Yes. It is mandatory to add password encoder in server.properties,
otherwise server can not decode password.
It works for me when I add password.encoder.secret to server.properties.
I have an application running on Wildfly 10 in a domain setup with more than 10 machines. Clients consume REST webservices using SSL authentication, in this scenario we will be adding clients on a daily basis so it is important to be able to propagate changes on the Truststore to the whole server group.
It's not an option to centralize the truststore in one machine due to concurrency levels.
I would like to know if there is a way to achieve this using the CLI or any other alternatives.
Thanks in advance!
Given that Wildfly does not support reloading the truststore at runtime (see https://access.redhat.com/solutions/482133), you would copy the truststore file to all servers (by hand, by script, by Puppet/Ansible/your DevOps tool), and use CLI to restart the affected server groups in the domain.
See also https://github.com/wildfly/quickstart/tree/10.x/helloworld-war-ssl for an example to implemet SSL auth. Basically all clients get a certificate from your own CA, which you add to the truststore once. Then use RBAC for the authorization.
I'm working on Jboss 5 and WAS 7.
I was able to run my application via Mutual Authentication on Jboss following this doc,
https://community.jboss.org/wiki/SSLSetup/
Following the above doc I created server.keystore and server.truststore files that I injected into the Jboss server and everything works fine.
Now, I want to run the same application via Mutual Auth on WAS.
On WAS, the trust store and keystore are specified by navigating to
Security > SSL certificate and key management > SSL configurations > New > Key
stores and certificates
But there I don't see any type related to .keystore and .truststore.(snap below)
My question - what is the equivalent of .keystore and .truststore that can be used in WAS OR what's the way to set up a Browser based Mutual Authentication on a WAS server.
I'm using WAS 7.0.0.21.
Keystores and truststores are the same format in WebSphere. You choose the file format, but any of those formats can be used for either store.
You then point a configuration at specific files.
Security > SSL certificate and key management > Manage endpoint security configurations
Alternatively, what has been simpler for us is to use the existing default stores WebSphere already has and add our certificates to those.
Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore
Or CellDefaultTrustStore or NodeDefaultKeyStore, etc.
The link helped me setup SSL on WAS. I just had to add a couple of steps to enable it for Browser based Mutual Authentication.
Since, I had to do a POC hence I'm using Self Signed Certificates.
In a ideal scenario Certificates will be signed by a Certificate Authority and the Certificate of Certificate Authority will be imported to the Trust Store of a WAS Server.
Here are the steps,
Change the password for Default KeyStore and Default TrustStore in WAS
Create a Client Certificate in WAS
Create a Server Certificate in WAS
Export the Client Certificate in PKCS format, e.g. client.p12
Export the Server Certificate in PKCS format, e.g. server.p12
Import the Client Certificate to Default TrustStore
Import the Server Certificate to Default TrustStore
Enable SSL on WAS.
i. Make sure the to select server certificate for both Default server certificate alias and the Default client certificate alias.
ii. In the Quality of protection (QoP) settings, choose Client Authentication as Required.
Create a Web Container Transport Chain with a new SSL port, e.g. 9444.
Add the newly created SSL port to the virtual Host.
Restart the Server.
Import the Client Certificate created in Step 4 client.p12 to the Browser.