How to Add SSL Certificate To AWS EC2

How to Add SSL Certificate To AWS EC2

How to Add SSL Certificate To AWS EC2? – Install an SSL certificate on your AWS EC2 Instance with these step-by-step instructions.

Steps to Install an SSL Certificate on AWS EC2 Instance

You’ve come to the right place if you’re looking for instructions on how to install an SSL certificate on an AWS EC2 instance. Before we get started with the actual AWS SSL certificate installation process, we’ll have a look at several conditions that must be met.

What to Do Before Installing an AWS SSL Certificate on EC2 Prerequisites: What to Do Before Installing an AWS SSL Certificate on EC2

Before you can install an SSL certificate on an AWS EC2 instance, you’ll need to have a few files on hand. Before we move on to the next phase, please look over the checklist below to be sure you have everything you need:

Prerequisites: What to Do Before Installing an AWS SSL Certificate on EC2

Intermediate certificates: When and if you received your server certificate in a zip package, these were very certainly supplied along with it. You may always download the CA Bundle for your certificate if you don’t have it.

This key should be kept in your possession or on the server (where you generated the certificate signing request).

After you have these files, you must PEM encrypt them before uploading them to your AWS account.

How to Convert Your AWS SSL Certificate to PEM-Encoded Format for EC2?

Certificates having a “.crt” extension obtained from the CA can be translated to PEM format (if they come with any other encoding formats like DER). This can be accomplished using either an online conversion tool or the OpenSSL library.

Note: The OpenSSL library can also convert certificate files from other formats like pkcs#7, pfx, and so on.

  1. To do so, use the command below to convert the server certificate format to PEM:
  2. To convert the certificate chain to PEM format.

Upload the Certificate to AWS Using CLI

Run the command below, adjusting it as needed, with your certificate files if you’re acquainted with the command-line interface (CLI).

To install your SSL certificate on an AWS EC2 instance, use the following command in your AWS account:

If you choose not to use the command-line interface, you can upload your certificates by following the steps in the next section.

5 Steps to Install SSL Certificate on AWS EC2 Instance

To upload the certificate to your AWS account, follow the steps below:

  1. Log into the AWS Management Console.
  2. Select your load balancer from the navigation pane by going to Services > Compute > EC2 > Load Balancers.
  3. On the Listeners tab, click Edit, then Add, and select HTTPS as the protocol.
  4. Click Change under the SSL certificate option, then choose Upload a new SSL certificate to AWS Identity and Access Management (IAM) from the Certificate type list.
  5. Click Save after entering the certificate name and pasting the contents of the individual certificate files (check that they are PEM encoded).

Prerequisites

Complete the following steps before beginning this tutorial:

  1. Create an Amazon Linux 2 instance with EBS support. See Step 1: Create an instance for further details.
  2. Configure your security groups to allow connections on the following TCP ports to your instance:
  3. SSH stands for Secure Shell (part 22)
  4. HTTP (Hypertext Transfer Protocol) (port 80)
  5. HTTPS is the secure version of HTTP (port 443)
  6. See Authorize inbound traffic for your Linux instances for additional details.

Install the Apache webserver on your computer. See Tutorial: Step-by-Step Instructions for detailed instructions. On Amazon Linux, set up a LAMP Web Server 2. You can skip the instructions concerning PHP and MariaDB because only the HTTPd package and its dependencies are required.

The TLS public key infrastructure (PKI) uses the Domain Name System to identify and authenticate websites (DNS). You must either register a domain name for your web server or transfer an existing domain name to your Amazon EC2 host in order to use your EC2 instance to host a public website. For this, you can utilize a variety of third-party domain registration and DNS hosting providers, or you can use Amazon Route 53.

Step 1: Enable TLS on the server

Check that Apache is running by connecting to your instance.

Perform a quick software update on your instance to ensure that all of your software packages are up to current. Although this procedure may take a few minutes, it is critical to ensure that you receive the most recent security and bug fixes.

Install the Apache module mod SSL to enable TLS support now that your instance is up to date.

To test, run the script to create a self-signed dummy certificate and key.

This file contains a self-signed certificate as well as the private key for the certificate. The certificate and key must be in PEM format, which is made up of Base64-encoded ASCII characters framed by “BEGIN” and “END” lines, as seen in the example below.

Using your favorite text editor (such as vim or nano), open the /etc/httpd/conf.d/ssl.conf file and comment out the following line, because the self-signed dummy certificate also contains the key. The Apache service will not start until you comment out this line before proceeding to the next step.

Apache should be restarted.

HTTPS (secure HTTP) on port 443 should now be supported by your Apache web server. To test it, type your EC2 instance’s IP address or fully qualified domain name into a browser URL bar with the prefix https://.

Your browser may display a series of security warnings because you are connecting to a site with a self-signed, untrusted host certificate. Ignore the warnings and go to the location.

If the default Apache test page appears, TLS has been enabled correctly on your server. All data exchanged between the browser and the server is now protected by encryption.

Step 2: Obtain a CA-signed certificate

To receive a CA-signed certificate, complete the steps below:

  • Create a CSR (certificate signing request) using a private key.
  • Submit the CSR to the appropriate certification authority (CA)
  • Obtain a signed certificate from the host.
  • Set up Apache such that the certificate is used.

1.A self-issued TLS X.509 host certificate is cryptographically equivalent to a certificate signed by a CA. The distinction is social rather than mathematical. Before providing a certificate to an applicant, a CA pledges to at the very least authenticate the domain’s ownership. To do this, each web browser has a list of CAs that the browser vendor trusts. An X.509 certificate is made up of two parts: a public key that corresponds to your private server key and a cryptographically linked signature by the CA. When a browser connects to a web server over HTTPS, the server sends the browser a certificate to verify against its list of trusted CAs. The browser negotiates a fast encrypted data channel with the server and loads the page if the signer is on the list or available through a chain of trust consisting of other trustworthy signers.

2.Because of the labor involved in authenticating the requests, certificates are often expensive, thus it pays to shop around. A few CAs provide free certificates at the basic level. The Let’s Encrypt project is the most well-known of these CAs, and it also offers certificate production and renewal automation. See Certificate automation: Let’s Encrypt with Certbot on Amazon Linux 2 for additional information on utilizing Let’s Encrypt as your CA.

AWS Certificate Manager is a good choice if you aim to provide commercial-grade services.

3.The key is hidden underneath the host certificate. For RSA keys meant to secure documents, government and industry associations propose using a minimum key (modulus) size of 2048 bits through 2030. OpenSSL on Amazon Linux 2 generates a default modulus size of 2048 bits, which is suitable for use in a CA-signed certificate. An optional step is included in the following procedure for individuals who desire a customized key, such as one with a greater modulus or one that uses a different encryption algorithm.

If you don’t have a registered and hosted DNS domain, you won’t be able to use these methods to get a CA-signed host certificate.

4.Create a new private key (optional). Here are some key configuration samples. Any of the keys that result function with your web server, but they differ in terms of the level and type of security they provide.

Make a CSR with the key you want to use. Custom.key is used in the following example.

5.OpenSSL displays a dialogue box in which you must enter the information listed in the table below. For a basic, domain-validated host certificate, all fields except Common Name are optional.

6.Finally, OpenSSL asks you for a challenge password, which is optional. This password is only for the CSR and transactions between you and your CA; heed the CA’s advice on this and the other optional field, optional company name. The CSR challenge password has no bearing on the server’s functionality.

Your public key, your public key’s digital signature, and the metadata you submitted are all contained in the csr.pem file.

7.Submit the CSR to a certification authority. This normally entails using a text editor to open your CSR file and putting the data into a web form. You may be requested to provide one or more subject alternate names (SANs) to be used on the certificate at this time. Example.com would be an excellent SAN if www.example.com is the common name, and vice versa. A visitor to your site who types in either of these names will see a connection that is error-free. Include the common name in the list of SANs if your CA online form allows it. Some CAs contain it by default.

8.You will receive a new host certificate signed by the CA after your request has been authorized. You may also be asked to download an intermediate certificate file containing additional certificates required to complete the CA’s chain of trust.

Keep in mind

Some CAs bundle the host and intermediate certificates into a single file, obviating the need for the SSLCACertificateFile command. Consult your CA’s instructions for more information.

In Apache’s SSLCertificateKeyFile directive, specify the path and file name of the private key (custom.key in this case):

Enter your domain name with the prefix https:// into a browser URL bar to test your server. The test website should load over HTTPS without any issues in your browser.

Step 3: Validate and strengthen the security setup.

You should test how secure your TLS is once it’s up and running and exposed to the public. This is simple to do using internet services like Qualys SSL Labs, which offers a free and comprehensive security audit. You can harden the default security setup by determining which protocols you accept, which cyphers you like, and which you exclude based on the findings. See how Qualys calculates its scores for more detail.

It is crucial

Real-world testing is critical for your server’s security. Small setup errors might lead to major data loss and security breaches. Periodic security audits are vital to good server administration since recommended security methods change regularly in response to research and emerging threats.

Enter the fully qualified domain name of your server in the form www.example.com on the Qualys SSL Labs site. You’ll get a grade for your site (from A to F) and a thorough description of the findings after around two minutes. The report for a domain with settings identical to the default Apache configuration on Amazon Linux 2 and a default Certbot certificate is summarized in the table below.

Keep in mind

This method of disabling TLS versions 1.0 and 1.1 prevents a tiny fraction of older web browsers from accessing your site.

To change the list of cyphers that can be used, go here.

Find the section containing the SSLCipherSuite directive in the configuration file /etc/httpd/conf.d/ssl.conf and comment out the existing line by inserting “#” at the beginning of the line.

Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) is an abbreviation for Elliptic Curve Diffie-Hellman Ephemeral. Forward secrecy is implied by the term ephemeral. These cyphers, as a result, do not support RC4.

Instead of relying on defaults or terse instructions whose substance isn’t evident, we propose using an explicit list of cyphers.

If you run the domain through Qualys SSL Labs again, the RC4 vulnerability and other warnings should be gone, and the summary should look something like this.

The encryption and password requirements on the key can be removed. Run the following commands on your EC2 instance to generate an unencrypted version of the key, assuming you have a private encrypted RSA key called custom.key in the default directory and the password is abcde12345.

The Electronic Frontier Foundation’s (EFF) project to encrypt the entire internet is centered on the Let’s Encrypt certificate authority. Let’s Encrypt host certificates are designed to be created, validated, installed, and maintained with little human intervention in order to achieve this purpose. A software agent running on your web server handles the automatic portions of certificate administration. The agent communicates securely with Let’s Encrypt and conducts administrative activities on Apache and the key management system after you install and configure it. The free Certbot agent is used in this tutorial because it allows you to either supply a customized encryption key as the basis for your certificates or let the agent build one based on its defaults. Certbot can also be set up to automatically renew your certifications on a regular basis, as discussed in To automate Certbot. Consult the Certbot User Guide and man page for more details.

Certbot isn’t officially supported on Amazon Linux 2, but it’s free to download and install, and it works fine. To preserve your data and avoid annoyance, we recommend that you make the following backups:

Take a snapshot of your Amazon EBS root volume before you begin. This allows you to return your EC2 instance to its initial condition. See Create Amazon EBS Snapshots for further information on how to do so.

The steps below will require you to make changes to your httpd.conf file, which governs Apache’s operations. Certbot makes modifications to this and other configuration files on its own. Make a duplicate of your whole /etc/httpd directory as a backup in case you need to restore it later.

Certificate automation: Let’s Encrypt with Certbot on Amazon Linux 2

The Electronic Frontier Foundation’s (EFF) project to encrypt the entire internet is centered on the Let’s Encrypt certificate authority. Let’s Encrypt host certificates are designed to be created, validated, installed, and maintained with little human intervention in order to achieve this purpose. A software agent running on your web server handles the automatic portions of certificate administration. The agent communicates securely with Let’s Encrypt and conducts administrative activities on Apache and the key management system after you install and configure it. The free Certbot agent is used in this tutorial because it allows you to either supply a customized encryption key as the basis for your certificates or let the agent build one based on its defaults. Certbot can also be set up to automatically renew your certifications on a regular basis, as discussed in To automate Certbot. Consult the Certbot User Guide and man page for more details.

Certbot isn’t officially supported on Amazon Linux 2, but it’s free to download and install, and it works fine. To preserve your data and avoid annoyance, we recommend that you make the following backups:

Take a snapshot of your Amazon EBS root volume before you begin. This allows you to return your EC2 instance to its initial condition. See Create Amazon EBS Snapshots for further information on how to do so.

The steps below will require you to make changes to your httpd.conf file, which governs Apache’s operations. Certbot makes modifications to this and other configuration files on its own. Make a duplicate of your whole /etc/httpd directory as a backup in case you need to restore it later.