目次
📋 1. 発生した問題
| 項目 | 内容 |
|---|---|
| 状況 | http（80番）では接続できるが、https（443番）でアクセスするとブラウザに「接続が拒否されました（CONNECTION_REFUSED）」と表示される。 |
| 環境 | Rocky Linux 9 / Apache (httpd) / Let's Encrypt (Certbot) |
| セキュリティ設定 | SELinux が Enforcing（有効）モード。 |
🔧 2. 原因と解決策（2つの大きな要因）
ポート（443番）の開放命令が不足していた
コマンド sudo ss -napt | grep 443 を打っても何も表示されなかった。これは、Apacheという「店」は開いているが、「HTTPS専用の入り口（443番ポート）」を誰も開けていない（Listenしていない）状態。
Rocky Linuxで mod_ssl を導入した際に作られる標準の ssl.conf には Listen 443 という命令が入っていた。しかし、初期エラーを回避するために ssl.conf を無効化したため、「443番ポートで待機せよ」という命令そのものが消えてしまっていた。
Apacheに443番ポートを監視するように明示的に命令を追加した。
sudo vi /etc/httpd/conf.d/listen443.confListen 443SELinuxによる証明書ファイルのアクセス拒否
ポートを開けても、ブラウザが拒否される、または「403 Forbidden」が出る。
SELinux（看守）は非常に厳格。Certbotが作成した「証明書ファイル」に対し、「これはApacheが触って良い証明書である」という正しいラベル（身分証）が貼られていなかった。
ラベルが etc_t（一般設定ファイル）のままだと、Apache（httpdプロセス）は cert_t（証明書用ラベル）以外のファイルを読み込むことが許されない。
restorecon コマンドを使い、証明書関連ファイルのSELinuxラベルを「本来あるべき姿（cert_t）」に貼り直した。
sudo restorecon -Rv /etc/letsencrypt/※ログに Relabeled ... from etc_t to cert_t と出れば成功。
🔍 3. 成功を確認した診断フロー
トラブル時に、どこが悪いかを特定するための「最強の確認コマンド」です。
1. サーバーの内部で動いているか？（これが最優先）
curl -k https://localhost→ これでHTMLが返ってくれば、ApacheとSELinuxの設定は「合格」。
2. ポートは開いているか？
sudo ss -napt | grep 443→ LISTEN 状態の行が出れば「合格」。
3. ファイアウォールは通しているか？
sudo firewall-cmd --list-all→ services に https があれば「合格」。
💡 4. 学習のポイント（まとめ）
- RHEL系の厳格さ：Ubuntuでは証明書を置くだけで動くが、Rocky Linuxでは「SELinuxのラベル（身分証）」が一致しないと、たとえ管理者(root)が置いたファイルでも拒否される。
- 設定ファイルの相互関係：一つのエラーを消すためにファイルを無効化（ssl.conf.bak）すると、そこに含まれていた重要な命令（Listen 443 など）まで消えてしまうことがある。「消す」のではなく「必要なものだけ別のファイルで再定義する」という考え方が有効。
- 内部テストの重要性：
curlコマンドで「自分自身」を叩くことで、問題が「サーバー内部の設定」にあるのか、「ルーターやネットワーク」にあるのかを切り分けることができる。
この記録を保存しておけば、今後同様の構成（Rocky Linux ＋ Apache ＋ SSL）でサーバーを構築する際、迷うことなく最短距離で「最強のセキュリティサーバー」を完成させることができます！
実機で確認した現在の状況
2026年8月4日時点で、本サイトのRocky Linux 9サーバーの実際の状態を確認しました。
$ curl -sk -o /dev/null -w 'HTTP %{http_code}\n' https://localhost
HTTP 200
$ ss -napt | grep 443
LISTEN 0 511 *:443 *:*- HTTPSでの内部接続が成功（TLSハンドシェイク＋証明書読み込みも成功、原因②のSELinux問題は解消済み） 証跡あり
- 443番ポートがLISTEN状態であることを確認 証跡あり
精査メモ：listen443.confのその後
この記録作成時点の応急処置だった /etc/httpd/conf.d/listen443.conf は、実機では現在存在しません。代わりに、当時無効化されていた標準の ssl.conf が復活しており（Certbotの再実行等で再生成されたとみられます）、そちらが Listen 443 を提供しています。応急処置のファイルが後日より正規の構成に置き換わった、という自然な経過です。
HTTPS接続問題 解決済み ✅
2つの原因（ポート未開放・SELinuxラベル不整合）はいずれも解消され、現在もHTTPS接続は正常に機能しています。