Configure SSL Endpoints and Certificates | MuleSoft Documentation
# Configure SSL Endpoints and Certificates
While you do not have to manage load balancers manually in CloudHub 2.0, each private space 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.
## Before You Begin
To associate an SSL endpoint, you must provide:
  * An encrypted, PEM-encoded (Privacy-Enhanced Mail) certificate file.
  * A second file containing the private key of your PEM certificate.


## Create a Certificate File and Private Key with the openssl Command
You can create both an encrypted, 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 -keyout example-com-private-key.pem -x509 -days 3000 -out example-com-crt.pem -passout pass:examplePassword
```

  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 encrypted, PEM-encoded file. Ordering is not important for independent CA certificates, but certificates in a chain of trust must be concatenated.