> I think the priority of `AuthenticationTls` must be higher. Then it
should be encouraged to use `AuthenticationTls` when TLS authentication is
enabled at broker side. Otherwise, these two options should be encouraged
to use.
You are right, if we are set up the `AuthenticationTls` and TLS transport,
we should use the `AuthenticationTls` data to set up, `AuthenticationTls`
must be higher. When the user set up two config, we need to throw an
expectation that only use the `AuthenticationTls`, or `tlsCertFilePath` and
`tlsKeyFilePath`.
Yunze Xu <y...@streamnative.io.invalid> 于2022年3月23日周三 01:57写道：
> If `tlsCertFilePath` and `tlsKeyFilePath` were added to the client builder
> options, I think they can also be used for TLS authentication as well.
>
> I prefer this solution now just because it looks like generating
> certificats
> automatically is not good, from what Enrico said.
>
> The problem is that what if we configured both `AuthenticationTls` and
> those
> two options? Because the underlying mechanisms are the same that a
> `SslContext`
> is created from the cert and key files and then the `SslContext` object
> will be
> used in the TCP or HTTP transport.
>
> I think the priority of `AuthenticationTls` must be higher. Then it should
> be
> encouraged to use `AuthenticationTls` when TLS authentication is enabled at
> broker side. Otherwise, these two options should be encouraged to use.
>
> Thanks,
> Yunze
>
>
>
>
> > 2022年3月22日 上午11:03，Zixuan Liu <node...@gmail.com> 写道：
> >
> > Hi Yunze,
> >
> > The current implementation is confusing, we should split the transport
> and
> > auth for TLS.
> >
> > For transport, the code can be so like:
> > ```
> > PulsarClient client = PulsarClient.builder()
> > .enableTls(true)
> > .tlsTrustCertsFilePath("ca.pem")
> > .tlsCertFilePath("client-ca.pem")
> > .tlsKeyFilePath("client-key.pem")
> > .build();
> > ```
> >
> > For auth, the code can be so like:
> > ```
> > Map<String, String> authParams = new HashMap<>();
> > authParams.put("tlsCertFile", "client-ca.pem");
> > authParams.put("tlsKeyFile", "client-key.pem");
> > PulsarClient client = PulsarClient.builder()
> > .enableTls(true)
> > .tlsTrustCertsFilePath("ca.pem")
> > .authentication(AuthenticationTls.class.getName(),
> > authParams)
> > .build();
> > ```
> >
> > When using the TLS auth, we don't need to set
> > tlsCertFilePath("client-ca.pem") and tlsKeyFilePath("client-key.pem"),
> the
> > authentication instead of this.
> >
> > There have an important thing that if we are using the authentication
> with
> > the token, we cannot setup the TLS transport.
> >
> >
> > Enrico Olivelli <eolive...@gmail.com> 于2022年3月22日周二 00:40写道：
> >
> >> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
> >> <y...@streamnative.io.invalid> ha scritto:
> >>>
> >>> Hi all,
> >>>
> >>> Recently I found a document error when configuring Pulsar client for
> TLS
> >>> encryption. See https://github.com/apache/pulsar/issues/14762.
> However,
> >> the code
> >>> example in the official documents is more intuitive.
> >>>
> >>> See
> >> https://pulsar.apache.org/docs/en/security-tls-transport/#java-client,
> the
> >>> example code doesn't configure `AuthenticationTls`, but it is required
> >> once TLS
> >>> encryption is enabled, even if TLS authentication is not enabled.
> >> Because the
> >>> client side can only send a SSL handshake via `AuthenticationTls`. It
> >> would be
> >>> confused.
> >>>
> >>> Since the cert file and the key file are generated using a CA, whose
> >> path is
> >>> specified by `tlsTrustCertsFilePath` method, I think it would be
> >> possible to
> >>> generate a cert and a key file automatically. We only need to specify a
> >> common
> >>> name, which represents the role when authentication is enabled.
> >>
> >> Usually a service cannot generate a "valid" certificate automatically,
> >> it MUST be signed by a CA.
> >>
> >> We may add an option to automatically generate a certificate (and a
> >> CA) but that will work only for
> >> DEV environments.
> >>
> >> Enrico
> >>
> >>
> >>>
> >>> My initial design is, when client configures the
> `tlsTrustCertsFilePath`:
> >>> - If no authentication plugin is enabled, generate the cert and key
> files
> >>> automatically using a default common name.
> >>> - Otherwise, use the cert and key files specified in
> `AuthenticationTls`.
> >>>
> >>> The benefit is, when you want to pass the TLS authentication, you must
> >> configure
> >>> `AuthenticationTls` at client side, while you only needs to configure
> >>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
> >>>
> >>> What do you think? Is there a better solution?
> >>>
> >>> Thanks,
> >>> Yunze
> >>>
> >>>
> >>>
> >>>
> >>
>
>
