Configure SSL Endpoints and Certificates | MuleSoft Documentation
# Configure SSL Endpoints and Certificates
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.
## See Also
  *   * Certificate Validation
  *   *