Tomcat運用で『この接続ではプライバシーが保護されません』!? Let's Encrypt 自動更新エラーの原因と解決策
2025-09-21 株主優待他
Webサイトを運用していたところ、先日、あるエラーが発生しました。
それが、これ
『この接続ではプライバシーが保護されません。』
Why?
調べてみたところ、暗号化通信の期限切れが原因。
ここで疑問に思ったのが、私のサーバでは暗号化通信の自動更新を設定してたはずなんです。それでも、エラーになった！
今回はその原因と対策を調べてみます！tomcatユーザー必見です！
環境
- OS: Linux (Ubuntu)
- Java: OpenJDK 11
- Tomcat: Apache Tomcat 9.x.x
- Web公開: Tomcat直運用（ApacheやNginxは介さず、80/443をTomcatが直接Listen）
- 証明書: Let's Encrypt（certbot使用）
自動更新設定
Let's Encryptより提供される自動化ソフトウェア(Certbot)を利用し、SSL/TLS証明書を発行していました。
原因
原因はポートにありました。
certbotは「standalone」モードで更新時に80番をcertbotが直接掴む必要があるのです。
で、私の環境ではTomcatが常時80番を使っているため、そのままだと更新ができなかったのです。
つまり、更新のときだけTomcatを止める処理が必要だったわけです。
手動更新の流れ
まずは、応急処置ということで、手動での更新作業を行ってみます。
tomcatを停止し、その間に証明書を更新し、tomcatを起動するという流れです。
# Tomcat停止
sudo xxx/tomcat9/bin/shutdown.sh
# 証明書更新（--standalone モード、ポート80/443を掴む）
sudo certbot renew --standalone
# Tomcat再起動
sudo xxx/tomcat9/bin/startup.shsudoで管理者権限で実行し、certbot renewですでに取得済みの証明書を更新します。--standaloneはcertbot 自身が一時的に Webサーバー（ACMEサーバーとの通信用のHTTPサーバー）を起動して更新処理をするモードです。
自動更新を設定
３つのファイルを作りました。
まずはタイマー設定ファイルです。
[Unit]
Description=Daily renewal of Let's Encrypt for Tomcat
[Timer]
# 毎日 04:30 に実行（0:00 はバッチが集中しがちなため少しずらす）
OnCalendar=*-*-* 04:30:00
Persistent=true
Unit=certbot-tomcat.service
[Install]
WantedBy=timers.targetこれはcronではなく、Linuxのsystemdを使用しており、「毎日4:30にcertbot-tomcat.serviceを起動して証明書更新を行う」設定にしています。
Persistent=true でサーバがその時間に落ちていても、次回起動時に補填実行し、WantedBy=timers.targetでサーバー起動時に自動でこのタイマーも有効になるように色々と保険をかけています。
２つ目のファイルは
[Unit]
Description=Renew Let's Encrypt (standalone) for Tomcat (stop -> renew -> start)
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
# Tomcat が動いてなくてもエラーにしないために "|| true" を付ける
ExecStartPre=/bin/bash -lc 'systemctl stop tomcat || true'
# 証明書更新（更新期限でない場合は「スキップ」して即終了）
# ※ --standalone なので 80 を certbot が一時占有
ExecStart=/usr/bin/certbot renew --standalone --quiet --no-random-sleep-on-renew
# 絶対に Tomcat を戻す（更新有無に関係なく）
ExecStartPost=/bin/systemctl start tomcat
# 念のためタイムアウトを長めに
TimeoutStartSec=900Unitの説明通り「Tomcat を停止して certbot renew を実行、その後 Tomcat を再起動する」ジョブです。
前にも記載しましたが--standaloneのため更新時だけcertbotが80番ポートを掴む仕様です。だから先に Tomcat を止めてます。
通常、renew(更新)は数分以内に終わるらしいですが、通信不良などを想定して長めに設定してます。
ExecStartPost(後処理)で本処理が終わったら必ずTomcatを再起動するようにしています。
3つ目のファイルは
[Unit]
Description=Apache Tomcat Web Application Container
After=network.target
[Service]
Type=forking
User=root
Group=root
Environment="JAVA_HOME=/usr"
Environment="CATALINA_HOME=xxx/tomcat9"
Environment="CATALINA_BASE=xxx/tomcat9"
ExecStart=xxx/tomcat9/bin/startup.sh
ExecStop=xxx/tomcat9/bin/shutdown.sh
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetこれはsystemdのユニットファイル（Tomcat をサービスとして管理するための設定ファイル）です。
これを設定すると、2つ目のファイルのような「$CATALINA_HOME/bin/startup.sh」や「shutdown.sh」がsystemdによって呼ばれ、systemdが色々と肩代わりしてくれるような設定になります。
つまり、systemd の仕組みを利用することで、運用上の安心と便利さを得られるようにしています。
設定を反映・自動化・テスト実行
先程作成したtomcat.serviceファイルを置いただけでは systemd は「ただの定義ファイル」として持っているだけです。そのため、下記コマンドでsystemd に認識させる必要があります。
# 1) systemd に最新の定義を読ませる（必須）
sudo systemctl daemon-reload
# 2) Tomcat を systemd 管理下で自動起動に
sudo systemctl enable --now tomcat
# 3) 毎日 04:30 の自動実行タイマーを有効化
sudo systemctl enable --now certbot-tomcat.timer
# 4) 次回実行予定の確認
systemctl list-timers --all | grep certbot-tomcatここで、重要なのは上記の操作をすると手動更新の流れでたたいたようなtomcatの更新をするとsystemdの管理状態と実際のプロセスの状態がずれて処理がうまくいかなくなる恐れがあります。
なので、今後は以下のコマンドでtomcatを操作する必要になります。
# 停止
sudo systemctl stop tomcat
# 起動
sudo systemctl start tomcat
# 状態確認
sudo systemctl status tomcat
# ログをリアルタイムで見る
sudo journalctl -u tomcat -fsystemd管理下で今すぐ実行するコマンドと、ログ確認のコマンドは以下です。
# 実行（Tomcat 停止 → certbot → Tomcat 起動）
sudo systemctl start certbot-tomcat.service
# 実行ログを確認（成功/失敗、停止/起動の順序）
journalctl -u certbot-tomcat.service -n 100 --no-pager確認は以下のコマンドで、
sudo systemctl list-timers --all | grep certbot-tomcatこれで「次回 04:30」と出れば、自動化設定は完全に成功してます！
まとめ
Tomcat直運用の場合、Let's Encrypt自動更新は標準のcertbot.timerでは失敗します。
解決策は「更新時だけTomcatを止める」仕組みをsystemdで用意することでした。
これで『この接続ではプライバシーが保護されません』エラーとはお別れです！
みっつー