Building MuleSoft APIs with HTTPs Endpoints & Self-Signed Certificates

When applications are deployed to CloudHub and exposed using SSL via the shared load balancer or a dedicated load balancer, the HTTP listener within the Mule application must also be configured for SSL.

One issue that arises when enabling SSL for the listener is being able to provide valid certificates for local testing before deploying to Cloudhub. Tools such as mkcert can make this process much easier.

{{cta(’21d05245-861a-4547-b6c1-8d565352ba15′,’justifycenter’)}}

Cloudhub Load Balancer Networking

When deploying apps to CloudHub you must be aware that the apps use a share load balancer unless you obtain a dedicated load balancer. Mule apps deployed in CloudHub must listen on host 0.0.0.0 and to either the HTTP port (8081) or to the HTTPS port (8082).

The following ports are assigned on the Mule worker by default:

• http.port is set to 8081

• https.port is set to 8082

CloudHub load balancers only forward the HTTP(:80) traffic to port 8081 and HTTPS (:443) to port 8082 on the worker. Forwarded traffic still uses HTTP and HTTPS protocols, which means it can’t listen for HTTPS on ${http.port} or plain HTTP on ${https.port}.

You must reference these ports using the reserved properties ${http.port} and ${https.port} respectively in your mule application as to property placeholders when you configure the port in your HTTP listener configuration. Since CloudHub services will allocate 8081 for HTTP and 8082 for HTTPS traffic at deployment time any custom values are provided for the above placeholder in mule-app properties they will be overwritten during deployment by CloudHub. If you have issues using these port numbers in the studio or local environment you could pass a required port number as VM arguments or have a different set of properties for deployments in the studio or local environment.

In order for the Load Balancers to forward the HTTPS traffic to the application, you need to configure your HTTP listener with a certificate, public-private key pair. The CloudHub load balancer does not validate the certificate you configure in your application so any self-signed certificate can be used irrespective of the host that it is generated for. When using a DLB you need to configure your DLB with a trusted certificate that the client validates with their trust store. You may need to provide them the certificate if you are using a self-signed certificate and not one signed by a trusted CA.

MuleSoft

The following Mulesoft documentation will provide all the information required for building an HTTPS endpoint. This includes generating a Keystore, self-signed certificate and how to configure your HTTP listener with TLS configuration. Refer to the below table for the required fields.

API development team.

Working With Self-Signed Certificates

It is difficult to work with self-signed certificates as they cause trust errors. Managing your own CA is the best solution, but usually involves arcane commands, specialized knowledge, and manual steps.

The mkcert utility can be installed in all development environments and it facilitates working with self-signed certificates much easier. The mkcert utility installs a trusted root CA into your system’s trust store. All the certificates generated using mkcert are signed using this root CA. This make’s all the certificates generated using mkcert as trusted. You need not make any configuration. Once you complete installing mkcert and setting required environment variables run the following command this will install a root CA into your system truststore.

mkcert -install

Here are the screenshots for the browser’s and Windows system’s truststore which have a mkcert’s rootCA as trusted.

keytool -list -keystore cacerts

mkcert -pkcs12 localhost

keytool -list -keystore C:UsersTejaChowdaryDesktopdemolocalhost.p12

keytool -importkeystore -srckeystore localhost.p12 -destkeystore NewDestinationKeystoreName -srcstoretype pkcs12 -deststoretype pkcs12 -alias 1 -destalias NewDestinationAlias -destkeypass NewDestinationPassword

Update the above -destkeystore -destalias and -destkeypass values with your required parameter from the snippet and run the command. Enter the destination password and source password “changeit“ in this case when prompted. Run the list command provided above with an updated path as an argument for -keystore to view the contents of the new Keystore.

Mulesoft documentation to configure your mule apps.

Working in Teams

When working in a team, team members need to use a single rootCA.pem file and install that in their system locally. This will make sure that a common root certificate entry is present in the systems’ Truststore of people working with the same certificates.

You can find the location for the rootCA certificate using the following command.

mkcert -CAROOT

mkcert -install

This will add the same rootCA entry on your system as trusted on to the new system’s truststore.

Configuring Postman

In order to work with self-signed certificates using Postman. Go to Postman settings, click on the certificates tab. In CA certificates add the rootCA.pem. If you are using a different certificate for each app since each certificate is signed by the same rootCA in your settings in postman they are then marked as valid during SSL verification.

MuleSoft Partner of the Year winner, recognized for enabling customers to accelerate their digital transformation and its excellence in project implementation and practice development.