blog.itcode.devblog.itcode.dev

[Raspberry Pi 4] Providing HTTPS Communication on an Ubuntu Server with Let's Encrypt

In the previous chapter, I obtained a dev domain through Google Domains. This blog's address actually uses the domain I purchased, https://blog.itcode.dev. The dev domain has an enhanced security policy applied. All HTTP communication to that domain must be served exclusively via HTTPS secure communication. Since routing happens over the https protocol at the network layer, providing an HTTPS service is mandatory whether we like it or not.

[Raspberry Pi 4] Providing HTTPS Communication on an Ubuntu Server with Let's Encrypt

In the previous chapter, I obtained a dev domain through Google Domains. This blog's address actually uses the domain I purchased, https://blog.itcode.dev. The dev domain has an enhanced security policy applied. All HTTP communication to that domain must be served exclusively via HTTPS secure communication. Since routing happens over the https protocol at the network layer, providing an HTTPS service is mandatory whether we like it or not.
RWB0104
@RWBwritten at 2021-09-06 07:50:40
Raspberry Pi

시리즈 모아보기

Raspberry Pi

5 / 7

In the previous chapter, I obtained a dev domain through Google Domains. This blog's address actually uses the domain I purchased, https://blog.itcode.dev.

The dev domain has an enhanced security policy applied. All HTTP communication to that domain must be served exclusively via HTTPS secure communication. Since routing happens over the https protocol at the network layer, providing an HTTPS service is mandatory whether we like it or not.


In this chapter, we'll obtain an SSL certificate from Let's Encrypt and apply it to Tomcat on the Raspberry Pi server. Instead of the conventional 1:1 domain-matched SSL, we'll get a wildcard certificate that covers all subdomains.

What is a wildcard certificate?
In programming, a wildcard means allowing arbitrary targets. Unlike a conventional certificate that matches 1:1 with a domain, a wildcard certificate is issued to the subject *.example.com and can be applied to all subdomains.

Let's issue an SSL certificate on the Ubuntu server. A typical SSL certificate verifies domain ownership by deploying a specific file to the web server during the verification process, then having the certificate authority validate access to and the validity of that file.
However, a wildcard certificate is a special certificate applied across multiple subdomains, so it doesn't use the verification method above. That method only guarantees ownership of a single domain. A wildcard certificate verifies ownership through a DNS record instead, because only the domain's owner can configure a DNS record.

If, for whatever reason, you can't change the domain's DNS settings, you won't be able to obtain a wildcard certificate.

Since we proceed with DNS record verification, there's no need to deploy any file to Tomcat, so you can carry out this process anywhere.

For how to issue a certificate on Windows, refer to the previously written post [SSL] Getting a Free SSL Certificate on Windows 10 with Let's Encrypt.

  • Ubuntu OS
  • Permission to configure DNS records

Since I purchased my domain through Google Domains, I can manage DNS settings there. If you purchased your domain through a different domain registrar such as Gabia, Whois, or Dothome, you can configure DNS on that site instead — keep that in mind.

This chapter proceeds based on Google Domains.

Install Certbot on Ubuntu.

BASH

sudo apt-get install certbot

Run Certbot to issue the certificate.

※ The itcode.dev domain below is only an example — when actually entering it, use your own domain.

BASH

sudo certbot certonly --manual --preferred-challenges dns --email psj2716@gmail.com -d *.itcode.dev
  • --manual - Manual configuration
  • --preferred-challenges - Specify the verification method
  • --email - Owner's email
  • -d - Specify the domain

Using the above command, you can perform verification immediately without much extra input. Enter the domain you purchased as the argument for -d, and don't forget to specify the subdomain as *.

OUTPUT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel:

This asks you to agree to the terms of service; enter A to agree. If you don't agree, you can't proceed with the SSL issuance.

OUTPUT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:

This is a question asking whether Certbot's development organization can send information such as web encryption efforts, EFF news, and events to the owner's email.

Enter Y if you're fine with it, or N if not. Declining doesn't affect the SSL issuance.

OUTPUT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:

This asks whether you consent to having your IP logged; enter Y to agree. If you don't agree, you can't proceed with the SSL issuance.

OUTPUT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.itcode.dev with the following value:

1sz-pJgM-3jL7mZacyByOO0S2lclAF0QmxtqujRuRHM

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

Certbot provides the subdomain name _acme-challenge along with a random string. All you need to do is assign the provided value, O3WQbIWv73aOzneZBu_4XAoE9ieZT1ZLdvbX7UPCkyk, to the DNS TXT record for the given domain, _acme-challenge.itcode.dev.

The domain will differ based on what value you entered, so keep that in mind.

There are several types of DNS records, such as A and CNAME. Among them, assign the value to a TXT record.

In Google Domains' DNS settings, add a record and set the type to TXT. Then enter the value provided by certbot. It may take a few minutes for the DNS settings to propagate. Propagation seems to be fast with Google Domains.

BASH

nslookup -q=txt _acme-challenge.itcode.dev

Since it's a TXT record, accessing that domain in a browser won't show anything meaningful. You need to look it up specifying the record type via the nslookup command.

OUTPUT

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
_acme-challenge.itcode.dev      text = "1sz-pJgM-3jL7mZacyByOO0S2lclAF0QmxtqujRuRHM"

Authoritative answers can be found from:

If the string you entered appears in that domain's TXT record as shown above, the DNS setting has propagated and you can proceed with verification. If no value appears, wait a bit longer.

Pressing Enter attempts verification, so never proceed until the DNS record configuration is complete.

Even though the DNS TXT record hasn't propagated yet, it's a common occurrence for someone's impatience to kick in and press Enter in certbot too early, moving on to the verification step.

If the TXT record isn't confirmed, certbot restarts the verification process along with a related message. The problem is that at this point, it generates a new string to register in the TXT record. In other words, you have to reassign the DNS TXT record with the updated value.

If DNS propagation is slow, the waiting time can add up significantly, so be careful. Always confirm whether DNS has taken effect using the nslookup command.

Once the DNS TXT record has propagated successfully, press Enter in the console to proceed to the next step. Certbot attempts verification, and once verification succeeds, it issues the certificate.

BASH

 # itcode.dev is the verified domain name
cd /etc/letsencrypt/live/itcode.dev

By default, the certificate is generated at the above path. The last folder, itcode.dev, is the domain name, so replace it with whichever domain you entered.

  • cert.pem - The domain's certificate
  • chain.pem - The issuing authority's certificate
  • fullchain.pem - The combined certificate of the domain and the issuing authority
  • privkey.pem - The certificate's private key

SSL verifies not just the domain's certificate, but also the certificate of the CA that issued it. Even if the domain's certificate is valid, if the issuing authority itself is untrustworthy, that certificate can't be trusted either. You can think of it as a kind of guarantee.

For example, the reason a 10,000 KRW bill in Korea has the value of 10,000 KRW is that the Bank of Korea guarantees it. In contrast, with hot cryptocurrencies, there's no institution guaranteeing their value. That's why their value fluctuates constantly and can lose its value and function at any time.

The purpose of fullchain.pem
You might think, since cert.pem and chain.pem are already provided, what's the point of a combined certificate for both? fullchain.pem combines the two certificates, allowing you to verify that cert.pem and chain.pem match.

The application method varies slightly depending on whether Tomcat Native is installed. SSL certificates are provided in the pem format by default.

Tomcat Native can recognize pem certificates directly, but a regular Tomcat installation can't recognize pem, so you'll need to convert it to another format such as jks.

BASH

sudo apt-get install libtcnative-1

On Ubuntu, you can apply Tomcat Native by installing the library above.

You can find detailed information in the post [SSL] Applying SSL to Tomcat.

Apply the certificate following the method in that post, restart Tomcat, and then try connecting via HTTPS, e.g. https://itcode.dev. Be sure to check the HTTPS service port before connecting. Tomcat's default HTTPS port is 8443.

If the HTTPS connection succeeds, you're done. You can also verify the certificate information.

  • Set up an Ubuntu server on the Raspberry Pi.
  • Run Tomcat to host pages.
  • Apply a domain.
  • Provide HTTPS communication by issuing an SSL certificate.
  • Set up remote communication environments such as SSH and RDP.
  • Install MariaDB to handle DB communication.
# Raspberry Pi# Ubuntu# Tomcat# SSL
ship
blog.itcode.dev

Notes from the π-th Alpaca

7.0.1
Developed by RWB since 2021.057th upgraded at 2026.08