Linuxエンジニア養成講座 第29回|全36回・フェーズ4「サーバー構築と運用」の第2回目(2/9回目)です。
前回: 第28回で SELinux の設計思想(MAC)を理解し、コンテキストの確認・修正・監査ログの読み方を実践しました。
今回学ぶこと: Apache(httpd)をインストールし、firewalld のポート許可と自己署名証明書による HTTPS 体験を通じて、Web サーバー構築の基本を身につけます。
前回の予告で「Apache のインストールから設定、自己署名証明書による HTTPS 体験までを行います。今回学んだ SELinux のコンテキスト設定(httpd_sys_content_t)や firewalld のポート許可(80/443)が必要になる」とお伝えしました。今回はその内容を実践します。フェーズ3で学んだ firewalld(第20回)と、前回の SELinux の知識を実際のサーバー構築で使います。
この記事を読み終えると、以下のことができるようになります。
- Web サーバーの役割と HTTP/HTTPS の違いを説明できる
- Apache(httpd)をインストールし、systemctl で起動・自動起動設定ができる
- firewalld で HTTP(80番)と HTTPS(443番)のポートを許可できる
- 自己署名証明書を使って HTTPS でアクセスできる
- httpd.conf の主要ディレクティブ(ServerRoot、Listen、DocumentRoot 等)の役割を説明できる
- Apache と Nginx の違いを概要レベルで説明できる
なぜ Web サーバーが必要か
ここで1つ考えてみてください。もし Web サーバーというソフトウェアがなかったら、サーバー上のファイルをどうやって他の人に配信するでしょうか。FTP でファイルを1つずつ転送する方法もありますが、世界中の何億人もの人が同時にファイルを取得する仕組みとしては成り立ちません。
Web サーバーは「HTTP(HyperText Transfer Protocol)というルールに従って、クライアント(ブラウザ)からのリクエストを受け取り、対応するファイルを返す」ソフトウェアです。普段ブラウザで Web サイトを閲覧するとき、裏側では必ず Web サーバーが動いています。
Web サーバーの役割は、大きく4つあります。
- コンテンツ配信: HTML、画像、CSS などのファイルをクライアントに返す
- アクセス制御: 特定の IP アドレスやディレクトリへのアクセスを制限する
- ログ記録: 誰が、いつ、どのページにアクセスしたかを記録する
- SSL/TLS 終端: 暗号化通信(HTTPS)を処理する
ここでもう1つ考えてみてください。もし通信が暗号化されていなかったらどうなるでしょうか。HTTP は通信内容が平文(暗号化されていない状態)でネットワークを流れます。ログイン画面で入力したパスワード、ECサイトで入力したクレジットカード番号、問い合わせフォームに書いた個人情報。これらがすべて暗号化されずにネットワーク上を流れます。
攻撃者がこの通信を傍受すれば、パスワードを盗んでアカウントを乗っ取る、クレジットカード番号で不正に買い物をする、個人情報を売買するといった被害が発生します。被害を受けるのはサーバーの管理者ではなく、そのサービスを利用しているユーザーです。
Web サーバーを構築するエンジニアは、ユーザーのデータを預かる立場にあります。HTTPS は「技術的なオプション」ではなく、ユーザーを守るための責任です。

HTTPS(HTTP over TLS)は、HTTP の通信を TLS(Transport Layer Security)で暗号化したものです。現在の Web では HTTPS が標準であり、HTTP のみのサイトはブラウザが「保護されていない通信」と警告を表示します。今回は自己署名証明書を使って HTTPS を体験します。
Apache(httpd)をインストールする
Apache HTTP Server は、世界で最も長い歴史を持つ Web サーバーソフトウェアの1つです。AlmaLinux では httpd というパッケージ名で提供されています。
今回は httpd 本体に加えて、HTTPS に必要な mod_ssl と、SELinux のコンテキスト管理に使う policycoreutils-python-utils もインストールします。policycoreutils-python-utils は前回使った semanage コマンドを提供するパッケージです。SP6(フェーズ3完了時点)のスナップショットには含まれていないため、改めてインストールします。
alma-mainで実行
実行コマンド:
$ sudo dnf install -y httpd mod_ssl policycoreutils-python-utils
httpd-core、httpd-filesystem、httpd-tools、mod_http2、mod_lua、sscg などが依存パッケージとして一緒にインストールされます。sscg は自己署名証明書を自動生成するツールで、mod_ssl のインストール時に証明書ファイルが自動作成されます(後ほど確認します)。
バージョンを確認します。
実行コマンド:
$ httpd -v
実行結果:
Server version: Apache/2.4.62 (AlmaLinux)
Server built: Dec 12 2025 00:00:00
第13回で学んだ systemctl を使って、Apache を起動し、OS 起動時に自動的に立ち上がるように設定します。
実行コマンド:
$ sudo systemctl start httpd
実行コマンド:
$ sudo systemctl enable httpd
実行結果:
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
status で動作状態を確認します。
実行コマンド:
$ systemctl status httpd --no-pager -l
実行結果:
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Sat 2026-04-04 11:38:18 JST; ...
Docs: man:httpd.service(8)
Main PID: 22159 (httpd)
Status: "Started, listening on: port 443, port 80"
Tasks: 177 (limit: 24743)
Memory: 23.8M
Active: active (running) と表示されていれば正常に起動しています。Status 行に port 443, port 80 と表示されていることから、HTTP(80番)と HTTPS(443番)の両方で待ち受けていることがわかります。mod_ssl をインストールしたため、443番ポートも自動的に有効になっています。
Apache の詳細な設定オプションは man httpd で確認できます。今は起動できれば十分です。
firewalld で HTTP/HTTPS を許可する
第20回で学んだ firewalld の実践です。Apache が起動していても、firewalld でポートが開いていなければ外部からアクセスできません。HTTP(80番)と HTTPS(443番)を許可します。
alma-mainで実行
実行コマンド:
$ sudo firewall-cmd --permanent --add-service=http --add-service=https
実行結果:
success
--permanent は再起動後も設定を維持するオプションです。--add-service=http は 80/tcp、--add-service=https は 443/tcp を許可します。サービス名で指定することで、ポート番号を覚えなくても済みます。
設定を反映します。
実行コマンド:
$ sudo firewall-cmd --reload
実行結果:
success
許可されているサービスの一覧を確認します。
実行コマンド:
$ sudo firewall-cmd --list-services
実行結果:
cockpit dhcpv6-client http https ssh
http と https が一覧に含まれていれば、外部からの HTTP/HTTPS アクセスが許可されています。
テストページを作成する
Apache が正常に動作しているか、テストページを作成して確認します。Apache のデフォルトのドキュメントルート(Web コンテンツを配置するディレクトリ)は /var/www/html/ です。
alma-mainで実行
実行コマンド:
$ echo "<h1>Hello from alma-main</h1>" | sudo tee /var/www/html/index.html
実行結果:
<h1>Hello from alma-main</h1>
tee コマンドは、標準入力を受け取ってファイルに書き込みつつ、標準出力にも表示するコマンドです。echo ... | sudo tee ファイル名 という形で、root 権限が必要なファイルへの書き込みによく使います(sudo echo ... > ファイル ではリダイレクト部分に sudo が効かないため)。
ここで前回学んだ SELinux のコンテキストを確認してみます。
実行コマンド:
$ ls -Z /var/www/html/index.html
実行結果:
unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
type フィールド(3番目)が httpd_sys_content_t になっています。これは「httpd プロセスが読み取れるコンテンツファイル」を意味する SELinux の type です。/var/www/html/ ディレクトリに直接ファイルを作成したため、親ディレクトリから正しいコンテキストを自動的に引き継いでいます。
もし別の場所で作成したファイルを cp でコピーしてきた場合、コピー元のコンテキストが付いたままになることがあります。その場合は前回学んだ restorecon で正しいコンテキストに修正する必要があります。
curl で HTTP アクセスを確認します。
実行コマンド:
$ curl http://localhost/
実行結果:
<h1>Hello from alma-main</h1>
テストページの内容が返ってきました。Apache が HTTP リクエストを受け取り、/var/www/html/index.html の内容を返していることがわかります。
HTTPS を体験する(自己署名証明書)
冒頭で「暗号化されていない通信は危険」という話をしました。ここから HTTPS を体験します。
mod_ssl をインストールしたとき、sscg(Simple Signed Certificate Generator)というツールが依存パッケージとして自動的にインストールされ、自己署名証明書が生成されました。そのため、追加の設定をしなくても HTTPS でアクセスできる状態になっています。
ssl.conf の主要設定を読む
まず、HTTPS の設定がどうなっているか確認します。
alma-mainで実行
実行コマンド:
$ grep -E "^(Listen|SSLCertificate)" /etc/httpd/conf.d/ssl.conf
実行結果:
Listen 443 https
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
各行の意味を確認します。
Listen 443 https: 443番ポートで HTTPS 接続を待ち受けるSSLCertificateFile: サーバー証明書ファイルのパス。クライアントに「自分はこのサーバーである」と証明するために使うSSLCertificateKeyFile: 秘密鍵ファイルのパス。証明書と対になる鍵で、暗号化通信に使う。このファイルが漏洩するとHTTPS の安全性が崩れるため、厳重に管理する
HTTPS でアクセスする
HTTPS でテストページにアクセスします。
実行コマンド:
$ curl -sk https://localhost/
実行結果:
<h1>Hello from alma-main</h1>
HTTP と同じ内容が返ってきました。通信経路が暗号化されている点が異なります。
-s は curl の進捗表示を抑制するオプション、-k は証明書の検証をスキップするオプションです。自己署名証明書は信頼された認証局(CA)が発行したものではないため、-k を付けないと証明書エラーになります。本番環境では、Let’s Encrypt などの CA から正式な証明書を取得するため、-k は不要です。
証明書の中身を確認する
openssl s_client コマンドで、サーバーが提示する証明書の情報を確認できます。
実行コマンド:
$ echo | openssl s_client -connect localhost:443 2>/dev/null | grep -E "subject=|issuer="
実行結果:
subject=C=US, O=Unspecified, CN=alma-main, emailAddress=root@alma-main
issuer=C=US, O=Unspecified, OU=ca-7633568812607075852, CN=alma-main, emailAddress=root@alma-main
subject は証明書の持ち主(このサーバー)、issuer は証明書の発行者です。自己署名証明書では subject と issuer が同じサーバー(alma-main)になっています。本番環境の証明書では、issuer に「Let’s Encrypt」や「DigiCert」などの認証局名が表示されます。
ブラウザで https://192.168.1.121/ にアクセスした場合、「この接続ではプライバシーが保護されません」や「安全でない接続」といった警告が表示されます。これは自己署名証明書がブラウザの信頼する認証局リストに含まれていないためで、正常な動作です。
ここで改めて考えてみてください。HTTPS を使わなかった場合、ネットワーク上の通信はすべて平文です。社内ネットワークであっても、同じネットワーク上の他の端末から通信内容を読み取られる可能性があります。暗号化のコスト(証明書の管理、わずかな処理負荷)と、暗号化しないリスク(情報漏洩、改ざん)を比較すれば、HTTPS を標準にすべき理由は明らかです。
httpd.conf の主要設定を読む
Apache のメインの設定ファイルは /etc/httpd/conf/httpd.conf です。主要なディレクティブ(設定項目)を確認します。
alma-mainで実行
実行コマンド:
$ grep -E "^(ServerRoot|Listen|User|Group|DocumentRoot)" /etc/httpd/conf/httpd.conf
実行結果:
ServerRoot "/etc/httpd"
Listen 80
User apache
Group apache
DocumentRoot "/var/www/html"
各ディレクティブの意味を確認します。
ServerRoot "/etc/httpd": Apache の設定ファイルやモジュールが格納されるベースディレクトリ。他のディレクティブで相対パスを指定した場合、このディレクトリが基準になるListen 80: HTTP リクエストを待ち受けるポート番号。HTTPS の 443 番は ssl.conf で別途設定されているUser apache/Group apache: Apache の子プロセスが動作するユーザーとグループ。root 以外の専用ユーザーで動作させることで、万が一侵害された場合の被害範囲を限定しているDocumentRoot "/var/www/html": Web コンテンツを配置するディレクトリ。ブラウザでhttp://サーバー名/にアクセスすると、このディレクトリの中身が返される
設定ファイルを変更した場合は、反映前に構文チェックを行う習慣をつけてください。
実行コマンド:
$ sudo apachectl configtest
実行結果:
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::4e48:b804:2646:376f%eth1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
AH00558 の警告は「ServerName ディレクティブが設定されていない」という内容です。これは httpd.conf に ServerName を明示的に設定していない場合に表示されるもので、動作に影響はありません。最後の行に Syntax OK と表示されていれば、設定ファイルの構文に問題はありません。
設定ファイルの詳細は man httpd や Apache 公式ドキュメントで確認できます。ディレクティブの数は多いですが、今の段階では上記の主要なものが読めれば十分です。現場で設定を変更する際に、必要なディレクティブを都度調べる方法を知っていることが大切です。
Apache と Nginx の違い
Web サーバーソフトウェアとして、Apache の他に Nginx(エンジンエックスと読む)が広く使われています。現場によってどちらを採用しているかは異なるため、違いを概要レベルで知っておくと役立ちます。
| 項目 | Apache | Nginx |
|---|---|---|
| アーキテクチャ | プロセス/スレッドベース(リクエストごとにプロセスまたはスレッドを割り当てる) | イベント駆動(少数のワーカーで大量の接続を処理する) |
| 設定ファイル | /etc/httpd/conf/ | /etc/nginx/ |
| 動的設定 | .htaccess でディレクトリ単位の設定変更が可能 | .htaccess に相当する仕組みはない |
| 得意な用途 | 動的コンテンツ処理、柔軟なモジュール構成 | リバースプロキシ、静的ファイル配信、高負荷環境 |
| AlmaLinux 9 | AppStream リポジトリから提供 | AppStream リポジトリから提供 |
今回は Apache でサーバー構築を体験しました。Nginx のインストールや設定は今回のスコープ外です。現場でどちらが使われているかは httpd -v や nginx -v で確認できます。今は「Web サーバーには Apache と Nginx という2つの主要な選択肢がある」ことを覚えておけば十分です。
現場のヒヤリハット
ヒヤリハット: firewalld でポートを開け忘れた
Apache をインストールし、curl http://localhost/ で正常に表示されることを確認。「よし、構築完了」と報告したところ、別のPCからブラウザでアクセスすると接続がタイムアウトする、というケースがあります。
原因は firewalld で HTTP/HTTPS のポートを開けていなかったことです。localhost(自分自身)へのアクセスは firewalld を経由しないため、ローカルでの確認だけでは気づけません。
切り分けの考え方は以下の通りです。
curl http://localhost/が OK → Apache 自体は動いている- 別の端末から
curl http://サーバーIP/が NG → ネットワーク経路の問題 firewall-cmd --list-servicesで http/https が含まれているか確認 → 含まれていなければ firewalld が原因
サーバー構築後は、必ず別の端末からもアクセス確認を行う習慣をつけてください。
ヒヤリハット: SELinux でカスタム DocumentRoot が拒否された
Web コンテンツを /var/www/html/ ではなく /srv/web/ や /home/developer/public_html/ に配置したい場面があります。DocumentRoot を変更し、パーミッションも正しく設定したのに、ブラウザには「403 Forbidden」が表示される。これは SELinux が原因です。
/var/www/html/ にはデフォルトで httpd_sys_content_t のコンテキストが付いていますが、/srv/web/ のような独自ディレクトリにはそのコンテキストがありません。httpd プロセス(httpd_t)は httpd_sys_content_t の type が付いたファイルしか読めないため、アクセスが拒否されます。
前回学んだ方法で解決できます。
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"でルールを追加sudo restorecon -Rv /srv/web/でコンテキストを反映
SELinux が原因かどうかは /var/log/audit/audit.log を確認することで判断できます。grep AVC /var/log/audit/audit.log で拒否ログが見つかれば、SELinux による拒否です。前回の知識がここで役に立ちます。
やってみよう
ここまでの知識を使って、以下の課題に取り組んでみてください。
課題1: 自分の HTML ページを作成して HTTP/HTTPS でアクセスする
/var/www/html/mypage.html というファイルを作成し、自分の名前やメッセージを含む HTML を書いてください。作成後、以下の2つの方法でアクセスできることを確認してください。
curl http://localhost/mypage.htmlcurl -sk https://localhost/mypage.html
確認のポイント: ls -Z /var/www/html/mypage.html で SELinux のコンテキストが httpd_sys_content_t になっていることも確認してください。
課題2: firewalld の設定を確認する
firewall-cmd --list-services を実行し、出力に http と https が含まれていることを確認してください。もし含まれていなかった場合、今回学んだ手順で追加してみてください。
まとめと次回予告
今回のポイントを3つにまとめます。
- Apache(httpd)をインストールし、systemctl で起動・自動起動設定を行った。firewalld で HTTP/HTTPS を許可しないと外部からアクセスできない
- mod_ssl と sscg による自己署名証明書で HTTPS を体験した。本番環境では CA から正式な証明書を取得する
- SELinux のコンテキスト(httpd_sys_content_t)がWeb コンテンツの配信に必要であることを確認した。前回の知識が実際のサーバー構築で役立つ
次回は第30回「データベース基礎(MariaDB)」です。MariaDB のインストールから初期設定(mysql_secure_installation)、ユーザー作成、データベース作成、基本的な CRUD 操作、mysqldump によるバックアップまでを実践します。今回構築した Web サーバーとデータベースを組み合わせると、いわゆる LAMP スタック(Linux + Apache + MariaDB + PHP)の基盤が整います。
理解度チェック
以下の文が正しければ ○、誤りであれば × と答えてください。
問1: Apache のデフォルトの DocumentRoot は /var/www/html/ である。
問2: firewall-cmd --add-service=http を --permanent オプションなしで実行した場合、OS を再起動すると設定が消える。
問3: 自己署名証明書を使った HTTPS 通信は、通信内容が暗号化されない。
問4: ssl.conf の SSLCertificateKeyFile に指定されるファイルは、外部に漏洩しても問題ない。
問5: Apache の子プロセスは、セキュリティのために root ユーザーではなく apache ユーザーで動作する。
問6: /var/www/html/ 以外のディレクトリに Web コンテンツを配置する場合、SELinux のコンテキスト設定が必要になる場合がある。
答え: 問1 ○ / 問2 ○ / 問3 ×(自己署名証明書でも通信は暗号化される。信頼された CA が発行していないだけで、暗号化の仕組み自体は同じ) / 問4 ×(秘密鍵が漏洩すると HTTPS の安全性が崩れるため、厳重に管理する必要がある) / 問5 ○ / 問6 ○
新卒からプロへ — Linux エンジニア養成講座 シリーズ一覧
フェーズ1: エンジニアのいろは
フェーズ2: Linux基礎
- 第4回 Linuxとは何か+環境確認
- 第5回 SSH接続とターミナル操作
- 第6回 ファイルシステムとディレクトリ構造
- 第7回 基本コマンド(ファイル操作)
- 第8回 基本コマンド(テキスト処理・パイプとリダイレクト)
- 第9回 viエディタ
- 第10回 ユーザーとグループ管理
- 第11回 パーミッションと所有権
- 第12回 プロセス管理
- 第13回 systemd
- 第14回 シェルスクリプト入門
- 第15回 フェーズ2まとめ演習
フェーズ3: ネットワークとインフラ基盤
- 第16回 ネットワーク基礎
- 第17回 ネットワーク設定と疎通確認
- 第18回 企業ネットワークの仕組み
- 第19回 パッケージ管理
- 第20回 ファイアウォール(firewalld)
- 第21回 ボンディング/チーミング
- 第22回 VLAN
- 第23回 ログ管理
- 第24回 cron / systemd timer
- 第25回 ストレージ管理(LVM)
- 第26回 シェルスクリプト実践
- 第27回 SSH応用
フェーズ4: サーバー構築と運用
- 第28回 SELinux
- 第29回 Webサーバー構築(Apache/Nginx)
- 第30回 データベース基礎(MariaDB)
- 第31回 バックアップと復旧
- 第32回 監視入門
- 第33回 セキュリティ実践
- 第34回 Git基本操作
- 第35回 自動化と構成管理(Ansible)
- 第36回 トラブルシューティング(総合演習・最終回)
