How to install SSL certificate on Amazon web service

Installing an SSL certificate on Amazon Web Services is different from installing one on a traditional Apache, Nginx, or IIS server. On AWS, the correct installation process depends on where HTTPS terminates. A certificate might be used by an Application Load Balancer, Network Load Balancer, CloudFront distribution, API endpoint, or directly on an Amazon EC2 instance, and each architecture handles certificates differently.

For most AWS deployments using managed services, AWS Certificate Manager (ACM) is the central place to request, import, and manage SSL/TLS certificates. ACM can work with certificates issued by AWS as well as certificates obtained from an external Certificate Authority. AWS states that ACM certificates are regional resources, so the certificate must be available in the appropriate AWS Region for the service using it. CloudFront is a notable exception because certificates used with CloudFront must be in the US East (N. Virginia) Region.

The important part is to identify your AWS architecture before uploading anything. If your website uses an Application Load Balancer, for example, you generally attach the certificate to the HTTPS listener rather than manually installing it on the EC2 instances behind the load balancer. If HTTPS terminates directly on an EC2 web server, the installation process is completely different.

Before Installing the Certificate, Identify Where HTTPS Terminates

The first question should not be “Where do I upload my SSL certificate?” It should be “Which AWS component is terminating the TLS connection?” This determines where the certificate belongs and prevents a common mistake where administrators install a certificate on an EC2 server even though the public HTTPS connection is actually terminating at an AWS load balancer.

A common AWS architecture looks like this:

Visitor
   |
   | HTTPS
   v
Application Load Balancer
   |
   | HTTP or HTTPS
   v
EC2 Instance
   |
   v
Application

In this architecture, the public certificate normally belongs on the Application Load Balancer. The EC2 server may still use HTTPS for the connection from the load balancer to the origin, but that becomes a separate TLS configuration.

AWS requires an HTTPS listener on an Application Load Balancer to have a certificate, and the certificate’s domain name must match the custom domain used by the connection.

AWS SSL Certificate Installation Options

There are several ways SSL/TLS certificates can be used with AWS, and they should not be treated as interchangeable installation methods.

For AWS managed services, ACM is generally the simplest approach because AWS integrates certificate deployment with services such as Elastic Load Balancing and CloudFront. ACM can issue certificates itself or accept certificates obtained from external Certificate Authorities.

If you already purchased a certificate from another CA, you do not necessarily need to replace it with an AWS-issued certificate. AWS allows compatible third-party certificates to be imported into ACM, provided the certificate, private key, and chain meet the required conditions.

What You Need Before Installing an SSL Certificate on AWS

Before opening the AWS console, collect the certificate files and confirm that they belong together. A typical third-party SSL certificate package contains the domain certificate, private key, and one or more intermediate certificates forming the certificate chain.

You should normally have:

• Certificate file: Your issued server certificate.
• Private key: The private key generated when the CSR was created.
• Certificate chain: The intermediate CA certificate or certificates required to connect your certificate to a trusted root.
• Domain name: The hostname covered by the certificate.
• AWS access: Permissions to use ACM and modify the AWS service where HTTPS will terminate.

The private key deserves particular attention. It is not something you should send through email, paste into tickets, commit to Git repositories, or store in publicly accessible locations. AWS requires an imported ACM private key to be PEM encoded, unencrypted, and no larger than 5 KB. The certificate and chain also need to meet ACM’s supported format requirements.

If your certificate files are in .crt, .cer, .key, or another format, do not assume that simply renaming the extension will convert them. The underlying encoding matters. If you need to prepare certificate files for AWS, this guide on creating a PEM file for SSL certificate installation covers the structure and conversion issues you may encounter.

Step 1: Check the Certificate Before Importing It

Before importing the certificate into AWS, verify that it actually matches the private key and covers the hostname you intend to secure. Uploading files without checking them first can lead to confusing import failures or a certificate that cannot be used correctly by the target AWS service.

At minimum, verify the following:

The hostname check is particularly important. If your application is accessed through www.example.com, a certificate issued only for example.net cannot be used to establish valid HTTPS for that hostname. AWS specifically requires the domain name on an Application Load Balancer certificate to match the custom domain record used for the connection.

Step 2: Import the SSL Certificate Into AWS Certificate Manager

If you purchased your certificate from an external Certificate Authority, the modern AWS workflow is to import it into AWS Certificate Manager.

Open AWS Certificate Manager, select the appropriate AWS Region, and choose the option to import a certificate. AWS’s current ACM documentation specifies three main pieces of certificate material for an imported CA-issued certificate: the certificate body, the matching private key, and, where applicable, the certificate chain.

The fields should correspond to:

Certificate body
      |
      +-- Your domain certificate

Private key
      |
      +-- Matching private key

Certificate chain
      |
      +-- Intermediate CA certificate(s)

Do not put the private key into the certificate body field, and do not treat the intermediate chain as the same file as the private key. Each item has a separate purpose during certificate validation and deployment.

AWS’s console import process specifically asks for the PEM-encoded certificate, unencrypted private key, and optional certificate chain before importing the certificate into ACM.

Step 3: Make Sure the Certificate Chain Is Correct

The certificate chain is one of the most common sources of SSL installation problems. Your website certificate is normally not the final trust anchor. The client needs to be able to build a path from the certificate presented by the AWS endpoint through the appropriate intermediate CA to a trusted root.

A simplified chain looks like this:

Trusted Root CA
       |
       v
Intermediate CA
       |
       v
Your Domain Certificate

When importing a CA-issued certificate into ACM, AWS requires the chain to be PEM encoded when you provide it. The certificates in the chain must also be correctly ordered so that each certificate directly certifies the certificate below it. AWS specifically warns that the end-entity certificate should not be included again in the certificate chain.

If you have previously encountered errors such as unable to get local issuer certificate, the problem may be the chain rather than the domain certificate itself. CompareCheapSSL’s guide to fixing the “unable to get local issuer certificate” error explains how to distinguish a missing server-side intermediate from a missing client-side trust anchor.

Step 4: Verify the Imported Certificate in ACM

After importing the certificate, do not immediately assume the installation is complete. The certificate first needs to be available in ACM in the same AWS Region as the service that will use it.

AWS treats ACM certificates as regional resources. If you have load balancers in multiple Regions, you generally need the appropriate certificate available in each Region. CloudFront has its own requirement: a certificate used by CloudFront must be in the US East (N. Virginia) Region.

This regional behavior causes a surprisingly common AWS mistake:

Certificate
   |
   v
ACM us-east-1

Load Balancer
   |
   v
ap-south-1

Result:
Certificate is not available to the load balancer

The certificate can be perfectly valid and correctly imported, yet AWS will not let the load balancer use it if it exists in the wrong Region.

Step 5: Attach the Certificate to an Application Load Balancer

If your website uses an Application Load Balancer, the next step is to associate the certificate with an HTTPS listener.

The listener is the component that accepts incoming connections on the load balancer. AWS requires an HTTPS listener to have a default certificate, and additional certificates can be associated with the listener when multiple hostnames are served through the same load balancer.

The general architecture becomes:

https://example.com
        |
        v
Application Load Balancer
        |
        | HTTPS Listener :443
        |
        +--- SSL/TLS Certificate
        |
        v
Target Group
        |
        v
EC2 / Application

In the AWS console, open EC2 → Load Balancers, select the relevant Application Load Balancer, and inspect its listeners. If there is no HTTPS listener, create one on port 443 and select the certificate available in ACM.

AWS’s current listener documentation allows you to select a certificate from ACM, select a certificate stored through supported IAM mechanisms, or import a certificate during listener configuration.

Step 6: Configure the HTTPS Listener Correctly

Installing the certificate is only part of configuring the listener. You also need to decide what should happen to HTTP traffic and what security policy the listener should use.

A typical configuration is:

Port 80
HTTP
  |
  | Redirect
  v
Port 443
HTTPS
  |
  v
Application

This allows visitors who enter http://example.com to be redirected to the secure HTTPS version.

The HTTPS listener should use an appropriate security policy rather than relying on outdated protocol configurations. AWS allows you to select a security policy when creating the HTTPS listener, so this is the point where TLS protocol and cipher configuration becomes part of the deployment.

The certificate itself does not determine all of the cryptographic behavior of the connection. The TLS policy and the AWS service’s supported cryptographic configuration also matter.

Step 7: Configure Multiple Domains Using SNI

If your Application Load Balancer serves several domains, you do not necessarily need a separate load balancer for every hostname.

AWS supports certificate lists on HTTPS listeners. The listener can have a default certificate and additional certificates, with SNI allowing the appropriate certificate to be selected based on the hostname supplied by the client.

For example:

              HTTPS Listener
                    |
        +-----------+-----------+
        |           |           |
        v           v           v
example.com   example.net   example.org
Certificate   Certificate   Certificate

This is especially useful for multi-domain applications where different hostnames need different certificates. If your architecture uses a single certificate to cover several names instead, make sure every required hostname is actually included in the certificate’s SAN field.

Step 8: Configure HTTPS Between the Load Balancer and EC2

One of the most important AWS SSL decisions is what happens after the load balancer decrypts the public connection.

You could have:

Visitor
   |
 HTTPS
   |
   v
Load Balancer
   |
 HTTP
   |
   v
EC2

Or:

Visitor
   |
 HTTPS
   |
   v
Load Balancer
   |
 HTTPS
   |
   v
EC2

The first architecture encrypts the external connection but uses HTTP between the load balancer and EC2. The second maintains TLS protection on both connections.

The correct choice depends on your threat model, network architecture, compliance requirements, and whether sensitive information travels between the load balancer and application server. Do not assume that traffic is automatically protected simply because the browser shows HTTPS.

This is closely related to SSL offloading and TLS termination, because the location where TLS terminates determines where plaintext application traffic can exist.

Installing the Certificate Directly on an EC2 Web Server

If you are running Apache or Nginx directly on an Amazon EC2 instance and users connect to that server without an intervening TLS-terminating load balancer, the certificate needs to be configured on the web server itself.

The process is similar to a conventional Linux server deployment: install the certificate, private key, and appropriate certificate chain, configure the HTTPS virtual host or server block, and reload the web server.

The important difference is that ACM certificates are not a general-purpose certificate file store that you can simply download and install onto an arbitrary EC2 Apache or Nginx server. AWS notes that ACM can be used with customer-managed infrastructure in certain scenarios, but the deployment model differs from attaching an ACM certificate directly to an integrated load-balancing service.

If you are installing a third-party certificate directly on EC2, pay particular attention to the PEM files and chain order. The PEM certificate installation guide is useful when your CA provides separate .crt, .cer, .key, or chain files.

Installing SSL on Amazon CloudFront

CloudFront requires a different approach because the certificate is associated with the CloudFront distribution rather than installed on an individual origin server.

If you use an ACM certificate with CloudFront, AWS requires the certificate to be in US East (N. Virginia), or us-east-1, regardless of where your origin server is located. This is one of the most important AWS-specific details to remember when configuring HTTPS through CloudFront.

The architecture may look like:

Visitor
   |
 HTTPS
   |
   v
CloudFront
   |
   | HTTPS or HTTP
   |
   v
AWS Origin

The CloudFront certificate secures the viewer-to-CloudFront connection. The connection from CloudFront to the origin is a separate decision and should be configured according to the security requirements of the application.

What Happens If You Import a Third-Party Certificate?

Importing an external certificate into ACM can be useful when you already purchased a certificate from a third-party CA or have an organizational requirement to use a particular issuer.

However, there is an important operational difference between an ACM-issued certificate and an imported certificate.

AWS automatically manages renewal for certificates that ACM issues under supported conditions. Imported certificates do not receive ACM managed renewal. When an imported certificate approaches expiration, you must obtain the replacement certificate from the issuing CA and reimport it into ACM. AWS explicitly places responsibility for monitoring and renewing imported certificates on the customer.

That means the installation workflow should not end with:

Certificate imported successfully.

You also need a renewal process.

How to Renew an Imported SSL Certificate on AWS

Suppose your imported certificate expires in 30 days.

Obtaining the replacement certificate from your CA is only the first part. You then need to import the replacement into ACM and make sure the AWS service is using the new certificate.

AWS supports reimporting a replacement certificate while preserving the certificate association and ARN in applicable cases. This can simplify deployments because services using the certificate association can continue using the same certificate resource while the certificate material is updated.

The operational sequence should therefore look like:

Certificate Approaching Expiration
          |
          v
Obtain Renewal From CA
          |
          v
Import / Reimport Into ACM
          |
          v
Verify Certificate
          |
          v
Verify AWS Service
          |
          v
Test HTTPS

Certificate renewal is therefore a lifecycle-management issue rather than simply an installation task. For larger environments, SSL certificate lifecycle management becomes important because certificates may exist across multiple load balancers, domains, environments, and AWS Regions.

Common AWS SSL Certificate Installation Errors

AWS certificate installation problems are often caused by configuration details rather than by a defective certificate.

Certificate Not Available in the Region

If the certificate was imported into ACM in one Region but the load balancer exists in another, it may not appear as an available certificate when configuring the listener.

Solution: Check the AWS Region shown in the ACM console and compare it with the Region containing the load balancer. Import or request the certificate in the required Region.

For CloudFront, remember the special us-east-1 requirement for ACM certificates.

Private Key Does Not Match the Certificate

ACM verifies that the private key corresponds to the public key contained in the certificate. If the wrong key is supplied, the import will fail.

Solution: Identify the private key used when the original CSR was generated and verify that it corresponds to the issued certificate before importing it.

Do not attempt to solve a private-key mismatch by changing file extensions. The cryptographic key pair must actually correspond.

Certificate Chain Is Missing

A certificate signed by a CA may require an intermediate certificate chain. If the required chain is missing or incorrectly formatted, ACM can reject the import or downstream clients can encounter trust problems.

Solution: Obtain the correct intermediate certificate bundle from the issuing CA and provide it as the certificate chain in the required PEM format. AWS specifically requires a CA-signed certificate’s chain to be PEM encoded when provided during import.

If the certificate imports successfully but clients still report trust problems, inspect the served chain rather than assuming the leaf certificate is defective. The certificate chain troubleshooting guide explains how trust is established from the leaf through intermediate certificates to the root.

Domain Name Does Not Match

A certificate can be valid and trusted but still be rejected if it does not cover the hostname the visitor is accessing.

For example:

Certificate:
example.com

Visitor:
www.example.com

Whether that connection succeeds depends on the names actually included in the certificate’s SAN field.

Solution: Inspect the certificate’s SAN entries and ensure every production hostname is covered. AWS requires the certificate domain name to match the custom domain used with an Application Load Balancer.

HTTPS Listener Uses the Wrong Certificate

If several certificates are associated with the same load balancer, SNI and certificate-list configuration determine which certificate is presented to a client.

Solution: Test each hostname individually and inspect the certificate actually returned for that hostname. Do not assume that because the correct certificate exists in ACM, the correct certificate is necessarily being presented to every domain.

If you encounter an SSL handshake or certificate mismatch after configuring the listener, the SSL handshake troubleshooting guide provides additional diagnostic approaches.

How to Verify That the AWS SSL Installation Actually Works

Seeing an imported certificate inside ACM does not prove that the public website is correctly configured.

After attaching the certificate, test the actual production hostname.

Check:

• HTTPS loads without a certificate warning.
• The certificate contains the correct hostname.
• The certificate has not expired.
• The expected CA is shown.
• The complete chain is trusted.
• HTTP redirects correctly if your architecture requires it.
• All required hostnames present the correct certificate.
• APIs and other HTTPS endpoints remain functional.
• The load balancer or CloudFront distribution is serving the expected certificate.

For a deeper inspection, command-line tools such as OpenSSL can show the certificate and chain presented by the live endpoint.

For example:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername option is important when testing modern HTTPS infrastructure because it sends SNI information. Without SNI, a multi-domain server or load balancer may return a different certificate from the one your browser receives.

You can also inspect the certificate details with:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

This helps verify the live certificate rather than merely examining the certificate file stored on your computer.

AWS SSL Installation Checklist

Before declaring the deployment complete, verify the entire path from the visitor to the application.

AWS SSL Installation Is About More Than Uploading a Certificate

The biggest mistake in AWS SSL deployment is treating certificate installation as a file-upload task. In cloud infrastructure, the more important question is where the TLS session terminates and which AWS service is responsible for presenting the certificate to the client.

If an Application Load Balancer handles HTTPS, the certificate belongs with the load balancer’s HTTPS listener. If CloudFront handles HTTPS, the certificate belongs to the CloudFront distribution and must be available in the required AWS Region. If EC2 terminates HTTPS directly, the certificate needs to be configured on the web server itself.

The certificate also needs to be part of a complete trust chain. The private key must match the certificate, the hostname must be covered, and the AWS service must be able to access the certificate in the correct Region. None of these checks can be skipped simply because the certificate was successfully issued by a trusted CA.

Finally, remember that installing an SSL certificate is only one part of securing an AWS application. TLS configuration, backend encryption, access controls, application security, certificate renewal, monitoring, and private-key protection all contribute to the final security posture.

Final Thoughts

Installing an SSL certificate on Amazon Web Services is straightforward once the AWS architecture is understood, but the exact process depends on where HTTPS terminates. For an Application Load Balancer, ACM and the HTTPS listener are normally central to the deployment. For CloudFront, the certificate must be available in us-east-1. For a standalone EC2 web server, the certificate is configured directly within the web server’s TLS configuration.

The safest workflow is to verify the certificate and private key first, prepare the complete certificate chain, import or request the certificate through the appropriate AWS mechanism, attach it to the actual TLS endpoint, and then test the live hostname. Do not stop at the point where ACM says the certificate exists; verify what real clients receive during the TLS handshake.

That final verification is what separates a certificate that is merely stored in AWS from an HTTPS deployment that is actually working correctly.