HTTPS를 위한 SSL 인증서 발급Issuing SSL Certificates for HTTPS

HTTP and HTTPS

HTTP

HTTP is the basic protocol for transferring data on the web. It sends data as unencrypted plain text, which makes it insecure.

HTTPS (HTTP Secure)

HTTPS is the secure version of HTTP, built by combining the HTTP protocol with the SSL/TLS protocol. It uses SSL/TLS certificates to vouch for a website’s authenticity. Because data is encrypted in transit, it is far more secure and protects your data from man-in-the-middle attacks, eavesdropping and the like.

SSL (Secure Sockets Layer) and Certificates

Let’s look at the SSL certificate you need for HTTPS communication.

SSL (Secure Sockets Layer)

SSL is a protocol that encrypts web traffic and keeps it secure. It was originally created by Netscape, and the standardized version that followed is called TLS (Transport Layer Security). Still, most people keep using the term SSL.

Certificates

A certificate is the core of SSL/TLS communication. You get verified by a trusted Certificate Authority (CA), which then issues you a certificate. The issued certificate contains important information such as:

1. Service information
   • Domain name
   • Organization name
   • Location, etc.
2. The server’s public key
   • The public key itself
   • The encryption algorithm used (e.g. RSA, ECC)

Types of Certificates

Certificates come in types based on how thoroughly they are vetted, and each type goes through a different level of trust and validation.

How Certificates Are Issued and Verified

The sequence diagram below shows the steps for HTTPS communication between a browser and a server. It breaks down into two main parts:

1. Getting an SSL certificate issued by a CA and setting it up on the server
2. The browser verifying and using the certificate for HTTPS communication

Here we’ll actually get a certificate issued by a CA and set it up on a server. Once you’ve done it yourself, the diagram below will be much easier to follow.

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'tertiaryColor': '#fff'
    }
  }
}%%
sequenceDiagram
    participant WS as Web server
    participant CA as CA (Certificate Authority)
    participant WB as Web browser

    WS ->>+ CA: 1. Certificate request : public key + server info

    %% Note right of CA: 2. Verify server info and create certificate
    %% Note right of CA: 3. Sign certificate with CA's private key

    CA ->> CA: 2. Verify server info and create certificate
    CA ->> CA: 3. Sign certificate with CA's private key

    CA -->>- WS: 4. Issue signed certificate to server

    CA ->> WB: 5. Provide CA's public key to web browser

    WB ->> WS: 6. Request to access server (website)
    WS -->> WB: 7. Send issued certificate

    WB ->> WB: 8. Verify certificate with CA public key

    WB ->> WB: 9. Encrypt symmetric key with server public key
    WB ->> WS: 10. Send encrypted symmetric key to server
    WS ->> WS: 11. Decrypt symmetric key with server private key

    WS  <<->> WB: 12. Exchange data encrypted with the symmetric key
    Note over WS, WB: HTTPS communication

Server Setup

We’ll use the following server specs:

• AWS EC2 : Amazon Linux 2023
• NGINX : nginx/1.26.2
• Public IPv4 DNS enabled, or your own domain

Installing NGINX

I installed version nginx/1.26.2 following nginx: Linux packages.

$ sudo yum install yum-utils

$ sudo vim /etc/yum.repos.d/nginx.repo

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/amzn/2023/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
priority=9

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/amzn/2023/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
priority=9

$ sudo yum install nginx

$ sudo systemctl restart nginx

Enabling Public IPv4 DNS

For the domain the CA needs to validate, we’ll use the Public IPv4 DNS. Go to ‘VPC’ > ‘Edit VPC settings’ and check ‘Enable DNS hostnames’. If you own a domain, you can use that instead.

Self-Signed SSL Certificate

First, let’s create a self-signed SSL certificate and apply it to NGINX.

1. Create the SSL Certificate

Start by generating a self-signed SSL certificate with OpenSSL. Create a folder and run the command below. It generates a 2048-bit RSA key pair and a self-signed certificate valid for one year. When you run it, you’ll be prompted to enter the certificate details.

$ sudo mkdir /etc/nignx/ssl

$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/self.key -out /etc/nginx/ssl/self.crt

• req : the command for creating certificate signing requests (CSRs) and certificates
• -x509 : creates a self-signed certificate with no signature from a public CA
• -nodes : short for ‘no DES’; the private key is not encrypted
• -days 365 : sets the certificate’s validity period to 365 days (one year)
• -newkey rsa:2048 : generates a new 2048-bit RSA key pair
• -keyout /etc/nginx/ssl/self.key : the path where the generated private key is saved
• -out /etc/nginx/ssl/self.crt : the path where the generated certificate is saved

2. Edit the NGINX Configuration File

Next, change the NGINX configuration to use SSL. Create a new config file in the /etc/nginx/conf.d/ directory or edit an existing one.

$ sudo vim /etc/nginx/conf.d/default.conf

Point the ssl_certificate directive at the self.crt file, and the ssl_certificate_key directive at the self.key private key file.

server {
    listen 443 ssl;
    server_name ec2-3-36-45-120.....; # change to your own domain

    ssl_certificate /etc/nginx/ssl/self.crt;     # certificate file
    ssl_certificate_key /etc/nginx/ssl/self.key; # private key file

    # SSL settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;

    # the rest of the server settings
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

# redirect HTTP to HTTPS
server {
    listen 80;
    server_name ec2-3-36-45-120.....; # change to your own domain

    # redirect every request to HTTPS
    location / {
        return 301 https://$server_name$request_uri;
    }
}

3. Check the NGINX Configuration & Restart

After editing the config file, check it for syntax errors. If the configuration is valid, restart NGINX to apply the changes.

$ sudo nginx -t

$ sudo systemctl restart nginx

If you’re on AWS, update the inbound rules of your Security Groups for http and https as needed.

Check in the Browser

The self-signed SSL certificate is now applied to NGINX. When you visit the site in a browser, you can see that a secure connection has been established. A certificate like this is fine for development or internal testing, but you can’t use it on a public production website, because it may show users a security warning.

> You can see the security warning and the self-signed certificate

CA Certificate : GOGETSSL

On the GOGETSSL site, you can get a CA certificate that is valid for 90 days. Log in, go to the SSL Certificates tab and choose Domain Validation. Find 90-day Trial SSL in the Product list and select it.

Issuing the Certificate

At first, the entry under SSL Certificates is created with a Status of Incomplete. Click the View button, then the Generate Certificate button to verify the server information and create the certificate.

CSR Configuration

A CSR is an encoded text file you submit to a CA to get an SSL certificate issued. You can create one by filling in the CSR Generation Form with the Online CSR Generator.

Filling in the CSR Generation Form

Enter your domain name in common name, the very first field of the CSR Generation Form. For a DV certificate, everything other than the domain can be anything you like. Click Generate CSR and two key values are generated.

Save the CSR Value and the Private Key

Copy the Certificate Signing Request (CSR) value that starts with the line below and paste it into Paste your CSR on the previous page (= CSR Configuration).

-----BEGIN CERTIFICATE REQUEST-----
MIICtTCCAZ0CAQAwcDELMAkGA1UEBhMCQlMxCjAIBgNVBAgMAXgxCjAIBgNVBAcM
...
-----END CERTIFICATE REQUEST-----

This part is important! Your Private Server Key is the private key you need to keep on your server. Make sure to save this file on your own server. We’ll save the private key at the path below.

$ sudo vim /etc/nginx/ssl/GoGetSSL_private.key

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC2EwrnXq5f6EtL
...
-----END PRIVATE KEY-----

Validation Methods

Choose http under Validation Methods, then fill in the required information.

Domain Validation

Under SSL Certificates, you can see the Status has changed to Processing. From the Domain Validation tab, download the server validation file (Validation File) and save it on the server.

Paste the contents of the downloaded file into the file at the path below.

$ sudo vim /usr/share/nginx/html/validation.txt

4182A51E1A437B4763ACE010E0DCEABEE1BCCEF81872BE2C0C8841C542C393F7
sectigo.com
t0031261001728017854

Update NGINX

Use the alias directive to point the validation URL directly at that file so it can be found. Wait a few minutes and the Status under SSL Certificates changes to Active, meaning server validation is complete.

server {
    # SSL settings
    ...

    # let the CA access the validation file
    location = /.well-known/pki-validation/350105A2....txt {
        alias /usr/share/nginx/html/validation.txt;
    }
}

Download & Upload All Certificate Files

The SSL certificate needed for HTTPS has now been created. Download everything with the All files button and upload the three certificate files to the server.

home/
├── ec-user/
│   └── ec2-3-...compute_amazonaws_com.crt 
│   └── GoGetSSL_RSA_DV_CA.crt 
│   └── USERTrust_RSA_Certification_Authority.crt

From these three files, we need to build a fullchain.crt file for the Chain of Trust. We’ll apply it to the server shortly.

Recap: Issuing a CA Certificate

That’s the whole process of getting a CA certificate issued. Let’s look at the diagram again and make sense of the steps.

Issuing a Certificate via a CSR

Let’s recall the order of what we did on the GOGETSSL site.

1. Generate a CSR
2. Save the private key on the server
3. The CA validates the server
4. The server’s certificate is issued

The CA digitally signs the server’s certificate with its own private key.

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'tertiaryColor': '#fff'
    }
  }
}%%

sequenceDiagram
    participant WS as Web server
    participant CA as CA (Certificate Authority)

    WS ->>+ CA: 1. CSR : public key + server info

    %% Note right of CA: 2. Verify server info and create certificate
    %% Note right of CA: 3. Sign certificate with CA's private key

    CA ->> CA: 2. Verify server info and create certificate
    CA ->> CA: 3. Sign certificate with CA's private key

    CA -->>- WS: 4. Issue signed certificate to server

The Certificate in the Browser

Thanks to the digital signature the CA put on the certificate, the browser can use the CA’s public key to verify that the certificate is valid.

A valid certificate contains the following:

• The server’s public key
• The server’s information
• The CA’s digital signature

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'tertiaryColor': '#fff'
    }
  }
}%%
sequenceDiagram
    participant WS as Web server
    participant CA as CA (Certificate Authority)
    participant WB as Web browser

    CA -->> WS: 4. Issue signed certificate to server

    CA ->> WB: 5. Provide CA's public key to web browser

    WB ->> WS: 6. Request to access server (website)
    WS -->> WB: 7. Send issued certificate

    WB ->> WB: 8. Verify certificate with CA public key

HTTPS

The browser has confirmed that the server’s public key inside the valid certificate can be trusted. Using that verified public key, the server and browser can now safely set up a symmetric key to share. That’s what makes HTTPS communication between the browser and the server possible.

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'tertiaryColor': '#fff'
    }
  }
}%%
sequenceDiagram
    participant WS as Web server
    participant WB as Web browser

    WB ->> WB: 8. Verify certificate with CA public key

    WB ->> WB: 9. Encrypt symmetric key with server public key
    WB ->> WS: 10. Send encrypted symmetric key to server
    WS ->> WS: 11. Decrypt symmetric key with server private key

    WS  <<->> WB: 12. Exchange data encrypted with the symmetric key
    Note over WS, WB: HTTPS communication

With the process above, we understand how the certificate proves the server’s public key is safe. But how do we know the certificate itself is valid?

How the Fullchain Works

Let’s look at the Fullchain approach used to verify that a certificate is valid.

• The CA at each level signs the certificate below it with its own private key.
• Each certificate is signed by the CA directly above it.
• The root CA’s certificate is self-signed.
• This repeats all the way up to the root CA, forming a chain of trust.
• The root CA’s certificate is usually preinstalled in browsers and operating systems, acting as the anchor point of trust.

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'tertiaryColor': '#fff'
    }
  }
}%%
sequenceDiagram
    participant WS as Web server
    participant LCA as Issuing CA
    participant ICA as Intermediate CA
    participant RCA as Root CA

    WS->>LCA: 1. Submit CSR
    LCA->>LCA: 2. Create and sign server certificate
    LCA->>ICA: 3. Request issuing CA certificate
    ICA->>ICA: 4. Create and sign issuing CA certificate
    ICA->>RCA: 5. Request intermediate CA certificate
    RCA->>RCA: 6. Create and sign intermediate CA certificate
    RCA-->>ICA: 7. Signed intermediate CA certificate
    ICA-->>LCA: 8. Signed issuing CA certificate
    LCA-->>WS: 9. Signed server certificate + certificate chain

The client (browser) follows this chain, verifying each certificate, until it finally reaches the root CA and confirms that the whole chain can be trusted.

Creating the fullchain.crt File

The server setup isn’t done yet, so let’s keep going. A fullchain file combines the several certificates that make up an SSL certificate chain into a single file. You create it by simply concatenating the certificate files into one.

$ cat (server.crt) (Intermediate.crt) [Root.crt] > fullchain.crt

$ cat ec2-3-...compute_amazonaws_com.crt GoGetSSL_RSA_DV_CA.crt USERTrust_RSA_Certification_Authority.crt > /etc/nginx/ssl/GoGetSSL_fullchain.crt

The Usual Order When Building a Fullchain File

The root certificate can be left out, since most browsers and operating systems already include it as a trusted certificate.

1. Server (domain) certificate
2. Intermediate certificate
3. Root certificate (optional)

NGINX Configuration

To use this fullchain file in NGINX, just point the ssl_certificate directive at it. The private key file goes separately in the ssl_certificate_key directive.

server {
    listen 443 ssl;
    server_name ec2-3-36-45-120.....;

    ssl_certificate /etc/nginx/ssl/GoGetSSL_fullchain.crt; # chain file
    ssl_certificate_key /etc/nginx/ssl/GoGetSSL_private.key; # private key

    ...
}

Full File Layout & NGINX Configuration

Full File Layout

etc/
├── nginx/
│   └── ssl/
│       ├── GoGetSSL_fullchain.crt 
│       └── GoGetSSL_private.key
usr/
├── share/nginx/html/
│               └── validation.txt

NGINX Configuration

server {
    listen 443 ssl;
    server_name ec2-3-36-45...;

    ssl_certificate /etc/nginx/ssl/GoGetSSL_fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/GoGetSSL_private.key;

    # SSL settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;

    # let the CA access the HTTP validation file
    location = /.well-known/pki-validation/257021C3....txt {
        alias /usr/share/nginx/html/validation.txt;
    }

    # the rest of the server settings
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

# redirect HTTP to HTTPS
server {
    listen 80;
    server_name ec2-3-36-45...;

    # redirect every other request to HTTPS
    location / {
        return 301 https://$server_name$request_uri;
    }
}

Wrapping Up

As groundwork for HTTPS communication, we studied how SSL certificates are issued. If you already know the basics of ‘public keys & private keys’, this material is a lot easier to follow.

It would also be worth studying the following topics. 😊

• The certificate renewal process
• Using Let’s Encrypt + CertBot
• Common problems and how to fix them (e.g. expired certificates, caveats when using self-signed certificates)

References

• Yalco (Shallow Coding Dictionary): What Is HTTPS and Why Use It? (Feat. Symmetric vs. Asymmetric Keys) (Korean)