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
>>>
>>>
>>>
>>>
>>
