What is the primary purpose of a Trust Store in the context of TLS within a Mule 4 application acting as a client?

To validate the identity of the remote server by verifying its certificate.

To store the Mule application's private key for encryption.

To provide public keys for data encryption by the client.

To store symmetric keys used for secure communication.

A Mule 4 application needs to securely connect to an external HTTPS endpoint (acting as a client). Which of the following is typically required in Mule's `tls:context` configuration to validate the server's identity?

Both a Key Store and a Trust Store

Neither is strictly required for client connections unless mutual TLS is used.

What information does a Key Store typically contain when Mule 4 is configured as an HTTPS listener to accept secure inbound connections?

The Mule application's private key and its corresponding public certificate.

Only trusted Certificate Authority (CA) certificates.

Public keys of clients for validation.

Symmetric encryption keys used for session encryption.

Consider a scenario where a Mule 4 application acts as an HTTP client making a call to an external service. If the external service presents a self-signed certificate, what action is needed in Mule 4's `tls:context` to successfully establish the connection without certificate validation errors?

Add the external service's self-signed certificate directly to Mule's Trust Store.

Configure a Key Store with the client's private key.

Disable SSL verification, though this is not recommended for production.

Request a new certificate from a public CA for the external service.

In a Mutual TLS (mTLS) handshake between a Mule 4 client and a Mule 4 server, how are the Key Store and Trust Store typically utilized by the *client*?

The client uses its Key Store to present its own certificate and its Trust Store to validate the server's certificate.

The client uses only its Key Store to authenticate itself to the server.

The client uses only its Trust Store to validate the server, and the server validates the client using its own Key Store.

The client uses its Key Store to validate the server's certificate and its Trust Store to present its own certificate.

A Mule 4 application is configured with an HTTPS listener, and clients are reporting 'certificate_unknown' errors during the TLS handshake. Assuming the server's certificate and private key are correctly configured in the Mule application's Key Store, what is the most likely cause of this error?

The client does not trust the Certificate Authority (CA) that issued the Mule application's server certificate.

The client's Key Store is misconfigured.

The Mule application's Trust Store is empty.

The client is attempting to use an unsupported TLS protocol version.

What is the fundamental difference in the role of a JKS (Java Key Store) file when configured as a `tls:key-store` versus a `tls:trust-store` within Mule 4's `tls:context`?

As a `key-store`, it provides the identity for the application (server); as a `trust-store`, it verifies the identity of external parties (clients/servers).

As a `key-store`, it holds private keys for authentication; as a `trust-store`, it holds public keys for encryption.

As a `key-store`, it is only used for outbound connections; as a `trust-store`, it is only used for inbound connections.

As a `key-store`, it stores symmetric keys; as a `trust-store`, it stores asymmetric keys.

TLS and trust store, and keystore in Mule 4

TLS and trust store, and keystore in Mule 4 - Test Paper