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

Reply via email to