SSL Certificate for Load Balancers
Describes how to use secure socket layer (SSL) certificates with your load balancer.
To use standard SSL with a load balancer and its resources, you must supply a certificate.
To use mutual TLS (mTLS) with your load balancer, you must add one or more certificate authorities (CA) or certificate authority bundles (CA bundles) to your system.
- Certificate Authority: A private certificate authority capable of issuing leaf certificates. For a load balancer and its associated resources, the CA is a trust store created inside certificates service and is not user uploaded.
- CA Bundle: A collection of CA public certificates that you can upload as an aggregated group. CA bundles do not include private key or leaf certificates.
It is recommended you upload the certificate bundles you want to use before you create the listeners or backend sets you want to associate them with.
You can perform the following SSL certificate tasks:
Load balancers commonly use single domain certificates. However, load balancers with listeners that include request routing configuration (see Request Routing for Load Balancers) might require a subject alternative name (SAN) certificate (also called multi-domain certificate) or a wildcard certificate. The Load Balancing service supports each of these certificate types.
The Load Balancing service does not generate SSL certificates. It can only import an existing certificate that you already own. The certificate can be one issued by a vendor, such as Verisign or GoDaddy. You can also use a self-signed certificate that you generate with an open source tool, such as OpenSSL or Let's Encrypt. Refer to the corresponding tool's documentation for instructions on how to generate a self-signed certificate.
If you submit a self-signed certificate for backend SSL, you must submit the same certificate in the corresponding CA Certificate field.
Oracle Cloud Infrastructure accepts x.509 type certificates in PEM format only. The following is an example PEM encoded certificate:
-----BEGIN CERTIFICATE----- <Base64_encoded_certificate> -----END CERTIFICATE-----
Converting to PEM Format
If you receive your certificates and keys in formats other than PEM, you must convert them before you can upload them to the system. You can use OpenSSL to convert certificates and keys to PEM format. The following example commands provide guidance.
Certificate or Certificate Chain from DER to PEM
openssl x509 -inform DER -in <certificate_name>.der -outform PEM -out <certificate_name>.pem
Private Key from DER to PEM
openssl rsa -inform DER -in <private_key_name>.der -outform PEM -out <private_key_name>.pem
Certificate Bundle from PKCS#12 (PFX) to PEM
openssl pkcs12 -in <certificate_bundle_name>.p12 -out <certificate_bundle_name>.pem -nodes
Certificate bundle from PKCS#7 to PEM
openssl pkcs7 -in <certificate_bundle_name>.p7b -print_certs -out <certificate_bundle_name>.pem
Configuring Peer Certificate Verification
Peer certificate verification is used for client authentication. Peer certificate verification depth is the number of certificates in the chain that need to be verified for client authentication.
The following are expected values to be set:
One intermediate certificate, client certificate, root certificate - 2
Client certificate, root certificate - 1s
To determine if your peer certificate verification is configured incorrectly, note the following:
The client indicates that it is unable to verify the certificate and results in a client SSL handshake failure. This error message varies based on the client type.
In the load balancer logs, the following error appears:
Client %s has SSL certificate verify error
Use the OpenSSL utility to run the following command:
openssl verify -verbose -CAfile RootCert.pem Intermediate.pem
An error occurs that shows at what depth the validation failure is occurring:
error 20 at 0 depth lookup:unable to get local issuer certificate
To resolve this situation, provide the correct certificate depth and confirm that the client certificate and certificate authority certificate match and are in the correct order.
Uploading Certificate Chains
If you have multiple certificates that form a single certification chain (for example, any intermediate certificate authority certificates), then include all relevant certificates in one file in the correct order before you upload them to the system. The correct order begins with the certificate directly signed by the trusted root certificate authority at the bottom of the list. Any additional certificates are pasted above the signed certificate.
Combine the server certificate (
SSL_Certificate.crt) and the
intermediate certificate authority certificate (
files into a single, concatenated file.
To get a single, concatenated file from the SSL certificate and the intermediate certificate authority certificate, open a command prompt and run the following command:
cat ssl_certificate.crt IntermediateCA.crt >> certbundle.pem
The following example of a concatenated certificate chain file includes four certificates:
-----BEGIN CERTIFICATE----- Base64-encoded_certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64-encoded_certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64-encoded_certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64-encoded_certificate -----END CERTIFICATE-----
Submitting Private Keys
Oracle recommends a minimum length of 2048 bits for your RSA private key.
If your private key submission returns an error, the three most common reasons are:
You provided an incorrect passphrase.
Your private key is malformed.
The system does not recognize the encryption method used for your key.
Key Pair Mismatch
If you receive an error related to the private key and public key being mismatched, then before uploading, use the following OpenSSL commands to confirm that they are part of the same pair:
openssl x509 -in certificate_name.crt -noout -modulus | openssl sha1 openssl rsa -in private_key.key -noout -modulus | openssl sha1
Confirm that the returned
sha1 hash values match exactly. If they
are different, then the private key provided is not used to sign the public
certificate and cannot be used.
Private Key Consistency
If you receive an error related to the private key, then you can use OpenSSL to check its consistency:
openssl rsa -check -in <private_key>.pem
This command verifies that the key is intact, the passphrase is correct, and the file contains a valid RSA private key.
Decrypting a Private Key
If the system does not recognize the encryption technology used for your private key, decrypt the key. Upload the unencrypted version of the key with your certificate bundle. You can use OpenSSL to decrypt a private key:
openssl rsa -in <private_key>.pem -out <decrypted_private_key>.pem
Configuring SSL Handling
Learn about configuring SSL handling for a Load Balancer resource.
You can perform the following SSL handling tasks for a load balancer:
Terminate SSL at the load balancer. This configuration is frontend SSL. Your load balancer can accept encrypted traffic from a client. No encryption of traffic exists between the load balancer and the backend servers.
Implement SSL between the load balancer and your backend servers. This configuration is backend SSL. Your load balancer does not accept encrypted traffic from client servers. Traffic between the load balancer and the backend servers is encrypted.
Implement point-to-point SSL. Your load balancer can accept SSL encrypted traffic from clients and encrypts traffic to the backend servers.
Terminating SSL at the Load Balancer
To terminate SSL at the load balancer, you must create a listener at a port such as 443, and then associate an uploaded certificate bundle with the listener. See Creating a Load Balancer Listener for more information.
Implementing Backend SSL
To implement SSL between the load balancer and your backend servers, you must associate an uploaded certificate bundle with the backend set. See Creating a Load Balancer Backend Set for more information.
If you want to have more than one backend server in the backend set, sign your backend servers with an intermediate CA certificate. The intermediate CA certificate must be included as part of the certificate bundle.
Your backend services must be able to accept and terminate SSL.
Implementing Point-to-Point SSL
To implement point-to-point SSL, you must associate uploaded certificate bundles with both the listener and the backend set. See Creating a Load Balancer Listener and Creating a Load Balancer Backend Set for more information.