To clarify, we are using a property name that matches the JDK name. Changing the property name would be an incompatible change, so it would require a period of deprecation. And for people familiar with JDK, it would be confusing. So, not clear it would be a good thing.
Ismael On Wed, Jun 1, 2016 at 2:29 PM, Ismael Juma <ism...@juma.me.uk> wrote: > Martin, > > What I said is correct, see: > > The JDK 8 release supports endpoint identification algorithms for TLS 1.2. > The algorithm name can be passed to the > setEndpointIdentificationAlgorithm() method of javax.net.ssl.SSLParameters. > The following table shows the currently recognized names. > Endpoint Identification > Algorithm NameSpecification > HTTPS http://www.ietf.org/rfc/rfc2818.txt > LDAPS http://www.ietf.org/rfc/rfc2830.txt > > > https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html > > Ismael > > On Wed, Jun 1, 2016 at 1:06 PM, Martin Gainty <mgai...@hotmail.com> wrote: > >> https is a protocol NOT an algorithm..no wonder this causes >> confusion!ssl.endpoint.identification.algorithmhttps:// >> en.wikipedia.org/wiki/Transport_Layer_Security >> ismael can you change ssl.endpoint.identification.algorithm property to >> ssl.endpoint.identification.protocolso the property matches what the >> accepted definition? >> >> Thanks, >> Martin >> ______________________________________________ >> >> >> >> > From: ism...@juma.me.uk >> > Date: Wed, 1 Jun 2016 11:31:58 +0100 >> > Subject: Re: SSL certificate CN validation against FQDN in v0.9 >> > To: users@kafka.apache.org >> > >> > Hi Phil, >> > >> > You are right that the check is not done by default. We have a couple of >> > JIRAs tracking that: >> > >> > https://issues.apache.org/jira/browse/KAFKA-3665 >> > https://issues.apache.org/jira/browse/KAFKA-3667 >> > >> > Enabling the check is a matter of setting >> > `ssl.endpoint.identification.algorithm` >> > to `https`, but please check the JIRAs for more details. >> > >> > Ismael >> > >> > On Wed, Jun 1, 2016 at 8:18 AM, Phi Primed <phipri...@gmail.com> wrote: >> > >> > > I using Kafka v 0.9 with TLS enabled, including client auth. >> > > >> > > In >> > > >> > > >> http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption >> > > , >> > > it is mentioned that "We need to generate a key and certificate for >> each >> > > broker and client in the cluster. The common name (CN) of the broker >> > > certificate must match the fully qualified domain name (FQDN) of the >> server >> > > as the client compares the CN with the DNS domain name to ensure that >> it is >> > > connecting to the desired broker (instead of a malicious one)." >> > > >> > > 1) Is there a specific additional configuration parameter to enable >> this or >> > > does it always happen if the other TLS/SSL parameters are set (as e.g. >> > > shown below) ? >> > > >> > > 2) Is it possible to make the broker(s) carry out the same check >> against >> > > client certificates if SSL client auth is enabled ? >> > > >> > > Regards, >> > > Phi >> > > >> > > >> > > listeners=SSL://:9093 >> > > >> > > authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer >> > > >> > > super.users=User:CN=broker1.mydomain.com >> ,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US >> > > >> > > ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks >> > > ssl.keystore.password=test1234 >> > > ssl.key.password=test1234 >> > > ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks >> > > ssl.truststore.password=test1234 >> > > >> > > ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1 >> > > ssl.keystore.type=JKS >> > > ssl.truststore.type=JKS >> > > >> > > security.inter.broker.protocol=SSL >> > > >> > > ssl.client.auth=required >> > > >> >> > >
