A TLS service needs to have a private key and a public certificate. The private key never leaves the server. The public certificate is exposed through TLS so clients can verify if they trust the server.
Certificates can be generated by a well-known Certificate Authority (CA) or can be generated locally without external approval (self-signed certificates). Certificates generated from Certificate Authorities include digital signatures and are usually accepted as trusted by any client that includes the CA certificate in its repository of trusted certificates (trust store).
For Mule products, certificates and private keys must be imported into Java keystore files. Trust store files are also keystores that by convention only include public certificates of trusted servers.
The 'tls:trust-store' and 'tls:key-store' elements must reference existing certificates. If you don’t provide any values for the trust-store, the default Java trust store is used. The default trust store is updated with the Java version, so it’s recommended that you use an updated Java version to be sure it includes updates to well known CA certificates.
To generate your own certificates, you can do so by following the steps below using Java Keytool.
Generating a Keystore
To generate a keystore that exposes your server’s credentials, run the command:
See AlsoThe minimum TLS version for Storage Accounts should be TLS1_2Enabling TLS 1.2 with SQL Serverkeytool -genkey -alias serverkey -keyalg RSA -keystore server.jks
The generated keystore will contain a private key and a public certificate. This certificate is self signed so it will be not be trusted by clients unless you share the public certificate with them.
| Keytool generates certificates using the DSA algorithm by default. You can instead specify it to use the RSA algorithm as in the example above through the '-keyalg RSA' argument. |
You will then be prompted for additional details, along with the store password and key password.
Once this is done, you must export the server’s certificate from the keystore so that it can be shared with clients. To do this, use the following command:
keytool -export -alias serverkey -keystore server.jks -file server_cert.cer
| There is no default Java key store in the standard JDK distribution, so you must generate your own certificates in order to use this element. |
If you also wish to get signed by a Certification Authority (CA), you must export your certificate in the standard CSR format. To do so you can run this command:
keytool -certreq -keystore server.jks -alias example.com -file certificate_fileHere, '-file' refers to the name you wish to give to your certificate file. Once generated, send the CSR file to the CA and follow their instructions to obtain their signature.
Once you have obtained the CA’s signature, you can import the signed certificate file through the following command:
keytool -import -keystore keystore -alias example.com -file signed_certificate_file| The alias you assign when importing must not be linked to any existing key or the process will fail. |
Generating a Trust Store
| The standard JRE distribution includes a default trust store with certificates for several major certificate authorities (CA’s) which is used by default in the 'tls:trust-store' element, but you can generate your own if you wish to have greater security or when using self-signed certificates. |
To create a trustStore, run the command:
keytool -import -alias serverkey -keystore client_truststore.ts -file server_cert.cer
The client will trust the server if a chain of trust can be established, either directly to the server (in case its certificate is in the trust store) or through a signing CA whose certificate is present in the trust store, failing otherwise. This means that a trust store must be defined when using self-signed certificates.
