Introduction

Transport Layer Security (TLS) certificates are a critical component of network security and ensure that data is securely transferred over third-party public networks.

To prevent man-in-the-middle (MITM) attacks, TLS trust must be configured correctly, with a clear understanding of how an organization obtains TLS certificates and validates the chain of trust.

Environment

Applications hosted in Mendix on Kubernetes

Details

In Mendix on Kubernetes, there are three separate types of TLS certificates that can be configured:

1. Client TLS certificates are used by a Mendix app as an authentication method, which are used when calling external services over protocols such as REST or SOAP.
2. Ingress TLS certificates are provided to clients (web browsers, smartphone apps, other applications, etc.) to prove that the network connection to the Mendix app is secure; as in, verified that the connection is protected against man-in-the-middle (MITM) attacks.
3. Root Certificate Authority (CA) trust configuration, which lists which certificate authorities should be trusted.

Client TLS certificates

Client TLS certificates are typically provided together with connection details for accessing an external REST or SOAP service (instead of a static password). 

In Mendix, Client TLS certificates need to be provided as password-protected PFX (PKCS12) files, on the Network tab in the Cloud Portal. It is possible to specify if a certificate should only be used for authenticating with specific hostnames or services. This hostname or service can then be called in the Mendix app to specifiy which certificate to use.

Client TLS certificates specified in Studio Pro (local) are intended only for test purposes and are not uploaded to the cloud. To use a Client TLS certificate in a Mendix on Kubernetes (Connected) environment, upload the client certificate via the Private Cloud Portal. For Standalone environments, the client TLS can be specified as a Kubernetes secret.

In modern Kubernetes environments, a service mesh such as Istio can be used to automatically generate and validate client TLS certificates.

Ingress TLS certificates

Most web browsers and operating systems include a default list of trusted certificate authorities. Any time a browser opens a website, it will check that the website's TLS certificate is signed by a trusted CA.

Any certificates signed by an unknown CA or that fail signature validation checks indicate a possible MITM attack and are considered to be unsafe.

In order to avoid having warnings in client browsers when opening a Mendix app, the app needs an ingress TLS certificate that:

• is issued by a trusted CA;
• matches the app's domain (possibly with a wildcard match);
• is valid (not expired and suitable for HTTP servers).

It's possible to upload an ingress TLS certificate via the TLS tab, as a *.pem certificate and private key. This is not recommended for production environments, as this way a copy of the certificate would be stored on third-party systems.

Instead, use a managed TLS certificate management system such as AWS ACM or cert-manager. This way, TLS certificates will have a shorter expiration date and will be rotated much more frequently than a manual TLS management process. These options also support private certificate authorities (when an organization's internal CA is used instead of a public CA).

For maximum compatibility, the *.pem certificate should include the complete certification chain, starting with the root CA and including all intermediate CAs.

As an alternative option, it's possible to attach an existing kubernetes.io/TLS Kubernetes secret with the ingress TLS cert, so that the private key never leaves the Kubernetes cluster.

Root CA trust

To ensure that Mendix on Kubernetes only accepts certificates from a trusted CA (private CA from an organization or from a trusted third party), a list of trusted Certificate Authorities needs to be specified in the Custom TLS trust tab in mxpc-cli or the Helm Chart UI.

Mendix on Kubernetes needs to be compatible with private CAs or DPI proxies such as ZScaler. It also needs TLS trust to be configured from the cluster side. If the Gateway Agent cannot connect to the Cloud Portal (because of a network proxy), it wouldn't be possible to configure TLS trust from the Cloud Portal. This is because there would be no connection from the Cloud Portal to the Agent. In addition, knowing a comprehensive list of trusted private CAs usually requires working together with network IT, as only network IT has a complete list of root CAs that an organization uses internally.

For these reasons, Mendix on Kubernetes only allows configuring TLS trust from the cluster side, by cluster admins. It is not recommended embedding root CAs into the app MDA, as an organization's IT team would then not be able to update the root CAs on their own.

Additional information

Mendix documentation:

• Certificates | Mendix Documentation
• Call REST Action with a Client Certificate | Mendix Documentation
• Certificates Tab | Mendix Documentation
• Running the Mendix Operator in Standard Mode | Mendix Documentation