Contact Free trial Login

Configure SSL Endpoints and Certificates

logo cloud active logo hybrid disabled logo server disabled logo rtf disabled

A dedicated load balancer must have at least one certificate associated with it. To configure an SSL endpoint for your load balancer to serve to clients, provide a certificate and private key pair for your load balancer.

A load balancer can have multiple and independent SSL endpoints, each identified by its server certificate common name.

Requirements

To associate an SSL endpoint, you must provide:

  • An unencrypted, PEM-encoded (Privacy-Enhanced Mail) certificate file.

  • A second file containing the private key of your PEM certificate.

    The private key file must be passphraseless.

Create a Certificate File and Private Key with the openssl Command

You can create both an unencrypted, PEM-encoded certificate file and a private key using openssl.

For example, to create a self-signed certificate and corresponding private key:

  1. Enter:

    openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem
  2. When prompted, enter the certificate information.

    This command creates two .pem files:

    example-com-crt.pem
    example-com-private.pem

    You upload these .pem files in Runtime Manager or pass them on the command line when you add an SSL endpoint to the load balancer.

Alternatively, you can pass a certificate information configuration file to the openssl command using the -config option.

For example, this certificate configuration file named example-com.cfg defines the DNS domain example.com that includes some SANs (Subject Alternate Names) for Mule applications app1.example.com and app2.example.com.

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt = no
[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName         = California
localityName               = San Francisco
organizationName           = MuleSoft
commonName                 = example.com

[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = app1.example.com
DNS.2   = app2.example.com

Run the following command:

openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem -config example-com.cfg

Create a Wildcard Certificate

You might want to create a wildcard certificate to support subdomain requests, for example, to support example.com and include app1.example.com and app2.example.com, as well as any future subdomain names.

To create a wildcard certificate that maps any subdomain name to example.com:

  1. Create a file that includes this configuration:

    [ req ]
    default_bits       = 2048
    distinguished_name = req_distinguished_name
    prompt = no
    [ req_distinguished_name ]
    countryName                 = US
    stateOrProvinceName         = California
    localityName               = San Francisco
    organizationName           = MuleSoft
    commonName                 = *.example.com
  2. Pass the certificate configuration file in an openssl command:

    openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem -config example-com.cfg
  3. Decrypt the private key using openssl:

    openssl rsa -in example-com-private.pem -out example-com-private-decrypted.pem

Configure Certificates for Production

Typically, in a production environment, your certificate is signed by a valid Certificate Authority (CA). Each SSL endpoint can have multiple CA certificates and CRLs (Certificate Revocation Lists). You must provide each of these certificates in a single unencrypted, PEM-encoded file. Ordering is not important for independent CA certificates, but certificates in a chain of trust must be concatenated.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub