Certificates
Introduction
Certificates are used to authenticate users to apps and secure communication. In Mendix Cloud, certificates can be used for both incoming and outgoing connections.
Incoming connection certificates can be managed either at the application level by Technical Contacts, or centrally by Mendix Admins via Certificate Management. Outgoing connection certificates are solely managed at the application level.
Incoming Connections
To connect to your Mendix Cloud application from the internet, Mendix provides a .mendixcloud.com or .mxapps.io domain. The certificate for this is managed by Mendix. If you want to set up your own domain name for a licensed app, you can configure custom domains.
In addition, you can restrict incoming traffic by requiring client certificates signed by a certificate authority of your choice. For more details on how to set this up, see How to Restrict Access for Incoming Requests.
Outgoing Connections
You may need to use certificates to set up connections from your Mendix Cloud application to third parties that require SSL/TLS. There are two possible scenarios for this:
- A third party may require authentication via certificates (client certificates)
- A third party may use a certificate that is signed by their own authority (certificate authorities)
Incoming – Certificates
Certificates for .mendixcloud.com and .mxapps.io are managed by Mendix and are automatically updated on a regular basis and without notice. This is part of Mendix's regular operations and security posture.
Using certificates with a short validity limits the impact of misconfigured or compromised certificates, which can occasionally happen. The wider internet community has standardized on this approach for many years.
Doing so can interrupt your operations when Mendix updates these certificates.
Pinning a certificate bypasses the built-in certificate chains of your operating system or JVM, and is widely considered a bad practice.
For situations where pinning is required, you can set up a custom domain where you are in full control of updating the certificate.
Outgoing – Client Certificates
For client certificates, only the Public-Key Cryptography Standard #12 (PKCS12) format is supported. Certificates are uploaded as a PKCS container that includes the following:
- X.509 certificate
- A private key
- (Optionally) a certificate chain
Virtually all certificate formats can be converted to the PKCS12 format. For more information, see the following:
- Create a PKCS12 (.pfx or .p12) from OpenSSL files (.pem, .cer, .crt, ...)
- OpenSSL Documentation
- Download OpenSSL for Windows
You can upload a PKCS12 file by following these steps:
From Apps, go to the Environments page of your app.
Click Details ( ) on the relevant environment.
Select the Network tab of an application environment.
In the Outgoing Connections Certificates section, click Add Client Certificate.
Upload the client certificate as a PKCS12 (.pfx or .p12) container.
Enter the password to unlock the certificate container.
In the section Use Client Certificate for specific services, you can specify host names (for example,
hello-there.com) or web service document names (for example, MyFirstModule.ConsumedWebService), indicating that this certificate should be used when contacting that host or calling that web service.If you are using a custom certificate when setting your Client certificate in your Call REST Service or Call Web Service action, you can set a Web Service Call Name and use it for the service by setting the Web Service Call Name to the call's Client certificate identifier.
Outgoing – Certificate Authorities
Loading certificate authorities works much the same way, although they do not require authentication because they are public certificates.
To upload a certificate authority, follow these steps:
From Apps, go to the Environments page of your app.
Click Details ( ) on the relevant environment.
Select the Network tab of an application environment.
In the Outgoing Connections Certificates section, click Add Authority.
Upload a certificate authority in the PEM format.
Frequently Asked Questions
Can You Create a *.mycompany.com Wildcard Certificate?
Yes. For application-level certificates, a wildcard certificate can only be used within the environments of a single app. This is because the private key is stored securely and cannot be accessed outside the app.
To reuse a wildcard certificate across multiple apps or environments, Mendix Admins can create a central certificate in Certificate Management. Central certificates can then be selected by Technical Contacts across different apps and environments.
Technical Contacts can select the same wildcard certificate for different environments of the same app by using it with different subdomains. For example, test.mycompany.com, accp.mycompany.com, and app.mycompany.com.
How Do You Construct an Intermediate Certificate Chain Properly?
Your certificate is signed by a certificate authority (CA) using the CA's intermediate certificate. The intermediate certificate is signed with the CA’s root certificate.
To reach the root certificate, you must link your certificate through the intermediate certificate chain, usually just one intermediate certificate. Occasionally, a CA requires multiple intermediate certificates.
- For application-level certificates, you provide the intermediate certificate chain when uploading the certificate at the application level
- For central certificates, the chain is uploaded by the Mendix Admin
You do not need to provide the root certificate, because every web browser has it in its trusted keystore.