---
schema_version: "1"
id: 37d4cf2682f9538d9f6c0c6aba7ebb2f70f29aa0ccf77f47de197e0d247424ca
title: Harden Your On-Premises Mule Runtime Engine Installation
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/on-premises/4.12/hardening-your-mule-installation.md
canonical_url: https://docs.mulesoft.com/on-premises/4.12/hardening-your-mule-installation
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 845e079bd2fe5c73f1bb899456b7cbc3296d1c697e7a14c2d64434a3a2ffb8ce
description: MuleSoft Documentation Site
release: "4.12"
latest: false
---
---
product: On-premises Runtimes
version: 4.12
keywords: hardening, FIPS, TLS, cipher suites, keystore, BCFKS, non-root, file permissions, on-premises, on-prem, standalone
---

# Harden Your On-Premises Mule Runtime Engine Installation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Harden on-premises runtime after Mule applications deploy successfully and before you use the
instance in production. Run as a non-root user, install as a service, restrict file permissions, and
configure TLS or FIPS. This is the Harden stage in [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.12/).

Use secure configuration files for passwords and keystores. Keep those files outside the Mule
application archive when DevOps must change them without a redeploy.

## Follow the Hardening Checklist

To harden on-premises runtime:

- Run Mule as a non-privileged user.

- Install Mule as a service. See
  [Start and Stop On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.12/starting-and-stopping-mule-esb).

- Configure Mule to write logs or temporary files in appropriate locations. Configure logs,
  passwords, and keystore files.

- Make usernames, passwords, and keystores available externally so DevOps can change them.

- Manage certificates in a keystore file.

- Use a separate property file to store usernames and passwords, and secure it using file system
  permissions.

- For FIPS, see
  [FIPS 140-2 Compliance Support](https://docs.mulesoft.com/mule-runtime/latest/fips-140-2-compliance-support) and
  [Download Your License Key](https://docs.mulesoft.com/on-premises/4.12/installing-an-enterprise-license#download-your-license-key).

### Run as a Non-Root User

Run on-premises Mule runtime engine as a non-root OS user. Root isn’t required except to bind ports
below 1024. The runtime user must own `$MULE_HOME` and have write permission to the logs directory.

On Linux and Unix, you can run Mule as any user with these caveats:

- You need write permissions to logs directory

- Without root you cannot use ports below 1024

On Windows, you need to be in admin user’s group to run Mule.

## Harden in Layers

By its nature, you can situate Mule in a variety of configurations. The suggested approach to
hardening involves hardening in layers beginning with the operating system, then working up the
stack. The Center for Internet Security (CIS) publishes configuration benchmarks that are widely
used in whole or in part as system hardening guides.

Commercial configuration management and integrity management tools can help you automate management
to the CIS benchmarks. Also, Mule documentation includes a good deal of information on configuring
security. If your application deals in sensitive data, consider using SSL Transport (HTTPS) to
protect it.

On the network security side, security experts recommend using a good stateful inspection network
firewall with a default-deny rule set and exceptions only for justified business needs. Also, any
internet facing server belongs in a DMZ with strong default-deny egress rules on the firewall to
prevent data exfiltration. Furthermore, you can use a network IDS/IPS to monitor and prevent known
attacks. Putting the database on an internal network - not the DMZ - also helps to harden your
installation.

Be sure your software developers are familiar with secure web application coding techniques. At the
very least, they should be familiar with best practices to avoid common web app pitfalls, such as
those listed in OWASP’s top 10 Project.

## Troubleshoot Common Error Messages

### `PKIX path building failed`

TLS trust failed while the on-premises runtime or Runtime Manager agent (`amc_setup`) connected to
an HTTPS endpoint. Import the issuing CA into the JVM truststore or configure the corporate proxy
certificate. This error isn’t a Mule application flow failure.

## See Also

- [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.12/)

- [Start and Stop On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.12/starting-and-stopping-mule-esb)

- [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/4.12/mule-deployment-model)

- [FIPS 140-2 Compliance Support](https://docs.mulesoft.com/mule-runtime/latest/fips-140-2-compliance-support)

- [Security](https://docs.mulesoft.com/mule-runtime/latest/securing)

- [Harden Mule Runtime on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)