ELB supports two types of certificates. If you need an HTTPS listener, you need to bind a server certificate to it. To enable mutual authentication, you also need to bind a CA certificate to the listener.
- Server certificate: used for SSL handshake negotiations if an HTTPS listener is used. Both the certificate content and private key are required.
- CA certificate: issued by a certificate authority (CA) and used to verify the certificate issuer. If HTTPS mutual authentication is required, HTTPS connections can be established only when the client provides a certificate issued by a specific CA.
Precautions
- A certificate can be used by multiple load balancers but only needs to be uploaded to each load balancer once.
- If a certificate is used for SNI, you need to specify a domain name for the certificate, and the domain name must be the same as that in the certificate.
- For each certificate type, a listener can have only one certificate by default, but a certificate can be bound to more than one listener. If SNI is enabled for the listener, multiple server certificates can be bound.
- Only original certificates are supported. That is to say, you cannot encrypt your certificates.
- You do not need to configure certificates for both the shared load balancer and the associated backend servers. If you configure a certificate for backend servers, HTTPS listeners cannot be added to the load balancer. In this case, you can add a TCP listener to transparently transmit HTTPS traffic to backend servers. This restriction does not apply to dedicated load balancers.
- You can use self-signed certificates. However, note that self-signed certificates pose security risks. Therefore, it is recommended that you use certificates issued by third parties.
- ELB supports certificates only in PEM format. If you have a certificate in any other format, you must convert it to a PEM-encoded certificate.
- If a certificate has expired, you need to manually replace or delete it.