カテゴリー: Linux Page 3 of 53

Apache全般のログローテーション設定。

サーバの移設中なので、ログに関しての記録を残しています。

概要

Webサーバ全般のメンテナンスで特に必要なのは

「ログを適切に管理する」

です。

  • 不審なアクセスの兆候
  • 自分のやらかし

を目の当たりにできる手段だからです。(特に後者に助けられたことは幾度となくあります)

そのため、Webサーバ上のログのローテーションを行い、履歴を追いやすくし、更にサーバの容量も削減するログローテーションを行います。

ログローテーションとは

ログファイルが肥大化するのを防ぐために、古いログを一定のルールに基づいて新しいログに切り替えたり、削除したりする仕組みのことです。

hogeサイトのアクセス記録である/var/log/access.logというファイルは、何も設定していないとログが記録され続けます。これによって以下の問題が起きます。

  • ログの肥大化によるサーバ容量の圧迫
    • テキストファイルぐらいと思う方がいるかも知れませんが、昨今の不正アクセスやAIサイトのクローラーのアクセス頻度は異常です。個人サイト程度でも一日数十MBはよくあります。
    • RedmineのようなWebアプリの場合、そのログは数百MBになります。
    • → このため、指定した期間でログを新しいログに差し替え、古いものは削除していくという仕組みを取ります。
  • ログの追記によるサーバのリソース増加
    • 追記自体の負荷は小さいですが、そのログをgrepなどで分析・検索する際に、巨大な単一ファイルだと非常に多くのメモリとCPUを消費します。
    • → ログを適切に分割(ローテーション)しておくことで、日々のログ分析が高速かつ軽量に行えるようになります。

これを行うべきタイミング

「Webサーバに新たなWebサイトやサービスを立ち上げたとき」 です。
試験運用などでもログは問題が起きたときのヒントとなるからです。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • apt(aptitude)によるパッケージ管理でインストールしているため、Apacheの実行ユーザはwww-dataです。

備考

ディストリビューションが違ってもこの手順は有効ですが、RockyやAlma等のRHEL系のApacheの実行ユーザは通常はapacheであることに注意しましょう。

さっくりとした手順

  1. (念のため)設定を行うサイトのログをwww-dataに変えます。
  2. ログローテーションのファイルを作成します。
  3. ログローテートの設定が有効かを確認します。

ここでは、hogeサイト(/var/log/hoge)のログをローテーションする方法です。

サイトのログの実行ユーザの変更(所有者変更)

これは、Redmineのlogプラグインのように、Webインタフェース上からログを閲覧できるプラグインがある場合、Apacheを実行しているサービス自体が参照できるようにするためです。

  • chownによる所有者変更
sudo chown -R www-data:www-data /var/log/hoge

ログ一式の所有者を変えます。ログファイルの形式は自分の環境に合わせます。

  • 所有者変更確認
ls -l /var/log/hoge

ログファイルの所有者とグループがwww-dataであることを確認します。

ログローテーションファイルの作成

ファイル名やログのパスは自分の環境に合わせます。 ここを間違えると元も子もありません。

cat <<- __EOF__ | sudo tee -a /etc/logrotate.d/hoge
/var/log/hoge/*.log {
    daily
    missingok
    rotate 10
    compress
    copytruncate
    notifempty 
    su www-data www-data
__EOF__

これは、以下を行います。

  • daiy
    • 1日ごとにローテーション
  • missingok
    • ログファイルが存在しなくてもエラーにしない
  • rotate 10
    • 10世代分の古いログファイルを保持する(それ以降は破棄)
  • compress
    • 古いログファイルをgzipで圧縮する
  • copytruncate
    • ログをコピーしてから元のファイルを空にする(サービス無停止でログ切替)
  • notifempty
    • ログファイルが空の場合はローテーションしない
  • su www-data www-data
    • ローテーション後のファイルの所有者を指定

他、週ごとやログのファイル形式(日付形式)などを設定できます。こちらは運用に合わせてください。

ログローテーションの確認

  • 設定確認
sudo logrotate -dv /etc/logrotate.d/hoge

※先ほど作成したファイル名に合わせます。

ここでエラーがなければログローテーションはできています。

  • ログローテーションの即時実行

すぐにローテーションを確かめる場合は以下を実行します。強制的にログローテーションを行うコマンドです。

sudo logrotate -f /etc/logrotate.d/hoge

このコマンドを実行後、/var/log/hoge/ディレクトリ内にaccess.log.1.gzのようなファイルが作成され、元のaccess.logが空になっていれば、設定は完璧です。

CPUとメモリ情報を表示するワンライナー。

概要

サーバスペックの要となる

  • CPU
  • コア数
  • メモリ量
  • スワップ量

を一度に表示するワンライナーです。

ワンライナー内容

awk 'BEGIN {FS=":"; OFS="\t"} /^model name/ && !cpu_model {cpu_model=$2; gsub(/^ */, "", cpu_model)} /^processor/ {cores++} /^MemTotal/ {mem_total=$2} /^MemAvailable/ {mem_avail=$2} /^SwapTotal/ {swap_total=$2} END {printf "CPUモデル\t: %s\n", cpu_model; printf "CPUコア数\t: %s\n", cores; printf "合計メモリ\t: %.2f GiB\n", mem_total/1024/1024; printf "利用可能メモリ\t: %.2f GiB\n", mem_avail/1024/1024; printf "合計スワップ\t: %.2f GiB\n", swap_total/1024/1024}' /proc/cpuinfo /proc/meminfo

実行結果

CPUモデル       : AMD EPYC-Milan Processor
CPUコア数       : 4
合計メモリ      : 5.78 GiB
利用可能メモリ  : 5.34 GiB
合計スワップ    : 2.00 GiB

と、分かりやすい表示で一気に表示してくれます。

Ubuntuでhistoryの履歴を追いやすくするシェルスクリプト並びにコマンド化。

概要

設定変更時、過去のコマンド履歴を確認するため

history | grep command

として過去の履歴を確認します。これをシェルスクリプトの力で解決します。(スクリプト作成にはGemini pro 2.5を利用)

スクリプト

  • histgrep.sh
#!/bin/bash

# スクリプトに引数が渡されたかどうかで処理を分岐
if [ "$#" -gt 0 ]; then
  # 引数が存在する場合、その値を検索文字列として使用
  SEARCH_TERM="$1"
else
  # 引数がない場合、対話式でユーザーに入力を促す
  read -p "探したいコマンドを入力してください: " SEARCH_TERM
fi

# 検索文字列が空の場合はエラーメッセージを出して終了
if [ -z "${SEARCH_TERM}" ]; then
  echo "検索文字列が入力されていません。"
  exit 1
fi

# historyコマンドの代わりに、履歴ファイルを検索する
HISTFILE_PATH="${HISTFILE:-$HOME/.bash_history}"

echo "実行履歴から「${SEARCH_TERM}」を含むコマンドは以下の通りです。"
grep "${SEARCH_TERM}" "${HISTFILE_PATH}"

これを保存して、

chmod +x histgrep.sh

で実行権限をつけます。

コマンド実行例

引数無しの対話型

./histgrep.sh
探したいコマンドを入力してください: bundle
実行履歴から「bundle」を含むコマンドは以下の通りです。
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle exec gem install rake
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo bundle install

と、探したい文字列を含む履歴をhistory(正確には履歴ファイル)から参照します。

引数型

./histgrep.sh configtest
実行履歴から「configtest」を含むコマンドは以下の通りです。
sudo apache2ctl configtest

このように、探したい文字列を引数とすることで、そのコマンドを探せます。

コマンド化

これをコマンド化します。

sudo ln -sf /path/to/script/directory/histgrep.sh /usr/local/bin/histgrep

/path/to/script/directory/histgrep.shはフルパスで、スクリプトがある場所を指定します。

which histgrep

で、/usr/local/bin/histgrepを確認。

後は、作業中でも

histgrep tar

などとすれば、過去に実行したコマンドの履歴を容易に参照することができます。

Redmine5.1にadditionalsをインストール

以前も書いていたadditonalsプラグインのインストール、Redmine5.1版です。

このプラグインの最新版はRedmine6.0のみ対応しています。そのため、ややバージョンの落ちるRedmine5.1で動かすには少し手間があります。

概要

Redmineにかなり強力なマクロを付与するプラグイン:additionalsをインストールします。

また、このプラグインは「additonal_tags」プラグインでも必要です。

プラグイン名

注意

2025年にリリースされているプラグインはRedmine 5.xをサポートしていないため、動くバージョン(タグ)をダウンロードしてのインストールです。

動作を確認した環境

  • Ruby 3.1
  • Redmine 5.1
  • Apache 2.4

さっくりとした手順

  1. SSHログイン後、作業ディレクトリに移動
  2. wgetでRedmine5.1に即したパッケージをダウンロード
  3. パッケージの配置
  4. 新規ジェムをインストール
  5. DBマイグレーション
  6. Webサービス再起動

作業用ディレクトリに移動します。

cd /hoge

任意のディレクトリに移動します

Redmine5,1に即したバージョンをダウンロードして展開します。

  • ファイル入手
wget https://github.com/AlphaNodes/additionals/archive/refs/tags/3.4.0.zip
  • zipファイルの所有者変更
sudo chown www-data:www-data 3.4.0.zip

apache / nginxの実行ユーザに所有者を合わせます

  • 解凍
sudo -u www-data unzip 3.4.0.zip

Redmineディレクトリにプログラムを配置します。

  • ファイル配置
sudo -u www-data mv additionals-3.4.0 /path/to/redmine/root/directory/plugins/additionals

このとき、リネームも行います。(-3.4.0を外す)

自分の環境に合わせます。(筆者環境/home/www-data/redmine/plugins/)

Redmineのルートディレクトリに移動します。

cd /path/to/redmine/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/redmine)

Gemをインストールします。

sudo -u www-data bundle install

DBのマイグレーションを行います

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

Webサービスを再起動します。

sudo systemctl restart apache2

動作確認

  1. Redmineに管理者アカウントでログインします。
  2. 管理に「Additionals」が加わっていればインストールされています。

公開用Redmineの整備。

別サイトとして運営している

(上記マルチドメインのため、どちらのサイトでも同じ内容です)

こちら、『ライザのアトリエ トリロジーDX』のリリースにより整備する必要が出てきました。

プロジェクトの追加とキャッチ画像の追加

プロジェクト - クーケン島観光ガイド

それぞれにBing Image Creatorで生成したアイコンを指定。

更に、今まで作っていなかったプロジェクトとして

概要 - 02_arライザのアトリエ1 - クーケン島観光ガイド

『ライザのアトリエ』を追加です。DX版に伴い、もう一度、最初からやっていき言語化していきたいなと思った次第です。

ただ、それまでの間に今止まっている

  • 『ユミアのアトリエ』のクエストなどの整理
  • 『ライザのアトリエ2』陽炎の島の装備の解説

など、やることは多いです。

出先での記録環境・確立。

先だって購入したThinkPad。

これを様々な場で使ってみます。

しかし、その前にアナログ環境の整備です。

まず、確固たるアナログ環境を整備。(オリジナルは林檎を収められますが、この暑さや湿気などで手が広がっているのが残念ですが、代わりに、大きな檸檬を持たせられるようになっています。

そして、出先ではThinkPad X13を使います。

訪れた場所は葛西臨海水族園。

やや天気が落ち着いた中での作業。屋外でも液晶は明るいまま。ちょっとした入力のみならず、本格的なアイディア出しにも威力を発揮です。

それ以上に、ここでの楽しみが食事。特にフィッシュカクテルのジャガイモはとても美味しく、パスタのトマトソースとの相性も抜群。

そして、記録を進めつつ魚も撮影。

こちら、どこでも記録ができるようになったことで、お気に入りの場所を「カフェ」のような使い方ができるようになっています。

Redmine_View_Customizeでチケットのステータスにラジオボタンを追加する

やりたいこと

Redmineのステータス一覧のドロップダウンリストにラジオボタンを追加し、ステータスの遷移を行いやすくします。

前提

  • Redmine View Customize がインストールされていること。
  • Redmine 5.1で動作を確認しています。

手順

画面移動

  1. Redmineに管理者権限でログインします。
  2. 管理>表示のカスタマイズに移動します。

カスタマイズ作成:JavaScript

表示のカスタマイズに移動後、「新しい表示のカスタマイズ」をクリックします。

以下の通りに入力します。

  • パスのパターン
  • /issues/[0-9]+
  • プロジェクトのパターン
  • 空白
  • 挿入位置
  • 全ページのヘッダ
  • 種別
  • JavaScript

コード

$(function() {
  const $select = $('#issue_status_id');
  if ($select.length === 0) return;

  const currentVal = $select.val();

  // ラジオボタンを入れるコンテナ
  const $radioContainer = $('<div class="status-radio-container"></div>');

  $select.find('option').each(function() {
    const val = $(this).val();
    const label = $(this).text();

    if (!val) return; // 空value(プレースホルダなど)はスキップ

    const id = 'status_radio_' + val;

    const $radio = $('<input type="radio">').attr({
      id,
      name: 'issue_status_radio',
      value: val
    });

    if (val === currentVal) {
      $radio.prop('checked', true);
    }

    const $label = $('<label>').attr('for', id).text(label);
    const $wrapper = $('<div class="radio-wrapper"></div>').append($radio, $label);

    $radioContainer.append($wrapper);
  });

  // ドロップダウンを非表示にし、ラジオボタンを挿入
  $select.hide().after($radioContainer);

  // ラジオ選択時に元のselectを更新
  $radioContainer.on('change', 'input[type=radio]', function() {
    $select.val($(this).val());
  });
});
  • コメント
  • 任意「チケットステータスにラジオボタンを追加する-JavaScript-」など
  • 有効
  • チェック
  • プライベート
  • チェックを外す

設定後、保存をクリックします。

カスタマイズ作成:CSS

表示のカスタマイズに移動後、「新しい表示のカスタマイズ」をクリックします。

以下の通りに入力します。

  • パスのパターン
  • /issues/[0-9]+
  • プロジェクトのパターン
  • 空白
  • 挿入位置
  • 全ページのヘッダ
  • 種別
  • CSS

コード

.status-radio-container {
  display: flex;
  flex-wrap: wrap;
  gap: 10px 20px;
  margin-top: 5px;
}

.radio-wrapper {
  display: flex;
  align-items: center;
  width: 220px; /* カラム幅は調整可能 */
}

.radio-wrapper label {
  margin-left: 6px;
  cursor: pointer;
}
  • コメント
  • 任意「チケットステータスにラジオボタンを追加する-CSS-」など
  • 有効
  • チェック
  • プライベート
  • チェックを外す

設定後、保存をクリックします。

動作を確認します。

任意のチケット編集画面をクリックします。

ステータス変更画面がドロップダウンリストからラジオボタンに変わっていれば成功です。

Google Geminiによるコード修正。(SSL証明書の有効期限確認)

このスクリプトの改善案をGoogle Geminiに言ったところ、更に完成度が上がりました。

概要

Web運用において、「サーバのSSL証明書更新」をチェックすることは大切です。

適切に更新されていない/更新が遅れたまま放置すると

  • ブラウザで「危険なサイト」と認識される
  • それによるレピュテーションリスク
  • HSTSを厳密に設定した場合はサイトそのものへのアクセス不可

など、リスクは甚大です。

そこで、

  • OpenSSLコマンドでドメインに設定されている証明書の期限
  • 並びに残り何日か

を表示するRubyスクリプトを準備しました。

スクリプト内容

  • ssl_checker.rb
#!/usr/bin/env ruby

require 'openssl'
require 'socket'
require 'date'
require 'uri'
require 'timeout'

# 色付け用の定数
COLOR_RED = "\e[31m"
COLOR_YELLOW = "\e[33m"
COLOR_GREEN = "\e[32m"
COLOR_RESET = "\e[0m"

# URLの最終的な到達先を取得するメソッド
def get_effective_url(url)
  # curlを使ってリダイレクトを追いかけ、最終的なURLを取得する
  # -s: サイレント, -L: リダイレクト追従, -I: ヘッダのみ, -o /dev/null: ボディ破棄, -w '%{url_effective}': 最終URLを出力
  effective_url = `curl -sLI -o /dev/null -w '%{url_effective}' "#{url}"`
  effective_url.empty? ? nil : effective_url
end

# 証明書の有効期限を取得するメソッド
def get_certificate_expiry_date(url)
  uri = URI.parse(url)
  hostname = uri.host
  port = uri.port || 443 # ポートがなければ443を使う
  ssl_socket = nil
  tcp_client = nil

  begin
    Timeout.timeout(5) do
      tcp_client = TCPSocket.new(hostname, port)
      ssl_context = OpenSSL::SSL::SSLContext.new
      ssl_socket = OpenSSL::SSL::SSLSocket.new(tcp_client, ssl_context)
      ssl_socket.hostname = hostname
      ssl_socket.connect

      cert = ssl_socket.peer_cert
      expiration_date = DateTime.parse(cert.not_after.to_s)
      days_remaining = (expiration_date - DateTime.now).to_i

      return expiration_date, days_remaining
    end
  rescue Timeout::Error
    return nil, "サーバーへの接続がタイムアウトしました。"
  rescue => e
    return nil, e.to_s
  ensure
    ssl_socket&.close
    tcp_client&.close
  end
end

# 結果を表示するメソッド
def print_result(url, expiration_date, days_remaining)
  if expiration_date
    formatted_date = expiration_date.strftime("%Y/%m/%d")
    
    # 残り日数に応じて色を選択
    color = if days_remaining < 14
              COLOR_RED
            elsif days_remaining < 30
              COLOR_YELLOW
            else
              COLOR_GREEN
            end

    puts "サイト #{url} の有効期限は #{formatted_date} です。#{color}残り #{days_remaining} 日です。#{COLOR_RESET}"
  else
    puts "#{COLOR_RED}サイト #{url} の証明書取得に失敗しました: #{days_remaining}#{COLOR_RESET}"
  end
end

# メイン処理
def main
  # コマンドライン引数があるかどうかで処理を分岐
  domains_to_check = if ARGV.empty?
                       # 引数がない場合は、対話式で入力を受け付ける
                       print "チェックしたいサイトのドメインを入力してください(例: example.com): "
                       [gets.chomp]
                     else
                       # 引数がある場合は、それらを全てチェック対象とする
                       ARGV
                     end

  # 各ドメインをチェック
  domains_to_check.each do |domain|
    # 対話モードで空エンターされた場合などをスキップ
    next if domain.nil? || domain.strip.empty?
    
    # http/httpsから始まらない場合はhttpsを付与
    initial_url = domain.start_with?('http') ? domain : "https://#{domain}"
    
    puts "Checking: #{initial_url} ..."
    final_url = get_effective_url(initial_url)

    if final_url.nil?
      puts "#{COLOR_RED}サイト #{initial_url} にアクセスできませんでした。#{COLOR_RESET}"
      next
    end
    
    expiration_date, days_remaining = get_certificate_expiry_date(final_url)
    print_result(final_url, expiration_date, days_remaining)
  end
end

# メイン処理を呼び出し
main

スクリプト実行例

ruby ssl_checker.rb

※Rubyで動かすためスクリプトに実行権は持たせる必要はありません

  1. 対話式でドメインを入力する
  2. 証明書の有効期限と残り期日を表示する
  3. ruby script.rb www.hoge.comなど、ドメインを引数にしても同様の効果が得られる
  4. 更新が近づくと
    • 30日以内:黄色
    • 15日以内:赤

とアラートも出してくれるようにしています。

  • 対話式
ruby ssl_checker.rb 
チェックしたいサイトのドメインを入力してください(例: example.com): www.yahoo.co.jp
Checking: https://www.yahoo.co.jp ...
サイト https://www.yahoo.co.jp/ の有効期限は 2026/05/14 です。残り 310 日です。
  • 引数にした場合
ruby ssl_checker.rb yahoo.co.jp www.msn.com
Checking: https://yahoo.co.jp ...
サイト https://www.yahoo.co.jp:443/ の有効期限は 2026/05/14 です。残り 310 日です。
Checking: https://www.msn.com ...
サイト https://www.msn.com/ の有効期限は 2025/10/05 です。残り 89 日です。

スクリプト使用例

筆者は/etc/update-motd配下に

ruby /path/to/script/ruby/ssl_checker.rb ryza.jp

と記入することで、ログインのたびに

Checking: https://atelier.reisalin.com ...
サイト https://atelier.reisalin.com/ の有効期限は 2025/08/15 です。残り 37 日です。

と次の更新のタイミングを読みやすくしています。

レポジトリを追加してのpassengerアップグレード。

概要

Redmineとの連携でmod_passangerを用いています。これのアップグレードメモです。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Ruby 3.2
  • mod_passenger 6.0.17 (アップグレード前)→6.0.27(アップグレード後)

バージョンアップの推奨メッセージ

var/log/apache2/error.logを確認したところ、

 [ E 2025-07-04 15:08:31.6489 116405/T5 age/Cor/SecurityUpdateChecker.h:521 ]: A security update is available for your version (6.0.17) of Phusion Passenger(R). We strongly recommend upgrading to version 6.0.27. 

と出たのでバージョンアップを行います。

  • バージョンアップ前確認
passenger-config --version

Phusion Passenger(R) 6.0.17

を確認。

対処1:aptitudeによるアップグレード → 更新されず

※筆者の好みでaptitudeを用いています。好みに応じてaptに変更してください。

sudo aptitude install passenger

を行いましたが、インストール・削除・更新されるパッケージがありません。と出たので、レポジトリの追加に伴うアップグレードを行いました。

対処2:レポジトリ追加後にaptitudeによるアップグレード → 更新OK

レポジトリ追加

  • 必要なツールのインストール

※導入済みであれば不要です。

sudo aptitude install dirmngr gnupg apt-transport-https ca-certificates curl
  • GPG鍵追加
curl https://oss-binaries.phusionpassenger.com/auto-software-signing-gpg-key.txt | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/phusion.gpg >/dev/null

これは、これから追加するリポジトリがPhusion社による本物であることを保証するための電子署名キーです。

  • Phusionのリポジトリ追加
sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger $(lsb_release -sc) main > /etc/apt/sources.list.d/passenger.list'

改めてaptitudeによるアップグレード

  • パッケージ更新
sudo aptitude update
  • mod_passanger更新
sudo aptitude install passenger

一式を

今度はアップグレードされました。

設定反映

  • Webサービス再起動

Ubuntu24.04はneedrestartにより、サービス再起動が必要なパッケージ更新が走った後は再起動してくれますが、念のため

sudo systemctl restart apache2.service

を行います。

バージョンアップ確認

passenger-config --version

Phusion Passenger(R) 6.0.27

と、アップグレードされていました。

Ubuntu24.04で、ワイルドカードSSL証明書をLet’s Encrypt(certbot)で発行する手順メモ。

筆者にとってこの作業は当たり前すぎていたため、メモを残すのを失念していました。

概要

Webサイトを公開する際に必須と言っていいSSL証明書を、Let's Encrypt(certbot)を用いて無料で発行する手順です。

今回用意するのはワイルドカード証明書です。

「*.example.com」という証明書を取得することで、

  • aaa.example.com
  • bbb.example.com
  • supercalifragilisticexpialidocious.example.com

など、サブドメインすべてに有効な証明書を1回で発行できます。

実施環境

  • Ubuntu 24.04

前提条件

  • ワイルドカー証明書を発行したいドメインに対してDNSの操作が行えること
    • できない場合は本手順そのものを無視してください。
  • 備考として、別サーバでも配布しやすいように、オリジナルの/etc/letsencrypt/live/ではなく、任意の作業ディレクトリに証明書一式を保存する運用を行っています。
  • 別サーバへの配布の際は注意してください。

さっくりとした手順

  1. certbotをインストールします。
  2. certbotでワイルドカード証明書を発行します。
  3. 証明書を発行します。
  4. 所定の位置に格納します。

certbotインストール

※すでにcertbotがインストール済の場合は、この手順はスキップして構いません。

  • snapによるインストール
sudo snap install --classic certbot
  • コマンド化
sudo ln -s /snap/bin/certbot /usr/bin/certbot
  • コマンド確認
which certbot

/usr/bin/certbotを確認します。

root昇格

性質上、rootで実行します。操作は慎重に行ってください。

sudo su -

作業ディレクトリ作成

  • ディレクトリ作成
mkdir /hoge/example.com_ssl$(date +%Y%m)

任意のディレクトリを指定します。$(date +%Y%m)オプションをつけているのは、Let's Encryptの有効期限が90日間と短いため、定期的に更新するためです。

  • ディレクトリ移動
cd /hoge/example.com_ssl$(date +%Y%m) && pwd

指定したディレクトリにいることを確認します。

ワイルドカード証明書の手動発行

※ ドメイン名やメールアドレスの打ち間違いは特に注意してください。このコマンドをコピー&ペーストし、自分のドメインやメールアドレスで間違いないように確認後に発行してください。

certbot certonly --manual \
    --preferred-challenges dns \
    --server https://acme-v02.api.letsencrypt.org/directory \
    -m あなたの有効なメールアドレス@example.com \
    -d "*.example.com" \
    -d "example.com"
  • --manualモードは非自動化のため、証明書更新のたびに手動でTXTレコード登録が必要です。自動化したい場合はDNS API対応のプラグインを検討してください(例:certbot-dns-cloudflare)。
  • certonly は証明書の取得だけを行い、Webサーバ設定などには手を加えないモードです。

以下のように実施します。

  1. コマンド発行後、TXTレコードの登録指示があります。
  2. 管理しているDNSサーバにて、指示があったTXTレコードを登録します。
  3. 以下のコマンドで結果が返ってくるまでしばらく待ちます。
nslookup -type=TXT _acme-challenge.example.com

→ 結果が返ってきたらEnter。証明書が作成されます。

証明書一式を作業ディレクトリにコピー

  • 証明書を作業ディレクトリにコピー
cp -pi /etc/letsencrypt/live/example.com/fullchain.pem ./example.com.crt.$(date +%Y%m)

※root権限のためsudoを用いないことに注意

  • 秘密鍵を作業ディレクトリにコピー
cp -pi /etc/letsencrypt/live/example.com/privkey.pem ./example.com.key.$(date +%Y%m)

(通例、証明書はroot権限でしか読めないように制限されています。読み取り時は注意してください)

証明書の整合性を確認

  • 90日の有効期限であることを確認します。

以下、自分が発行したドメインに基づく証明書や秘密鍵に読み替えます。

openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)
notBefore=May 17 04:35:55 2025 GMT
notAfter=Aug 15 04:35:54 2025 GMT

のように90日間であることを確認します。

  • 確認1. 証明書から公開鍵データを確認
openssl x509 -pubkey -in example.com.crt.$(date +%Y%m) -noout | openssl md5
  • 確認2. 秘密鍵から公開鍵を取得
openssl pkey -pubout -in example.com.key.$(date +%Y%m) | openssl md5

→ 確認1/確認2で出てきた公開鍵のハッシュ値が一致していればOKです。

  • 証明書のチェーンを確認
openssl crl2pkcs7 -nocrl -certfile example.com.crt.$(date +%Y%m) | openssl pkcs7 -print_certs -outform PEM | awk 'BEGIN {c=0;} /BEGIN CERTIFICATE/ {c++} { print > "cert" c ".pem"}' && openssl verify -CAfile cert2.pem cert1.pem
openssl verify -CAfile cert2.pem cert1.pem
cert1.pem: OK

となることを確認します。

確認後、

exit

でrootから抜けます。

証明書の配置

※Let's Encryptは3ヶ月(90日)しか有効期限がありません。

そこで、証明書更新の際にApacheの設定ファイルを修正することなく行えるように、証明書/秘密鍵ファイルにシンボリックリンクを張り、ファイル名.202507等とすることで「最後に発行したのはいつか」を確認します。

ディレクトリを作成します。

sudo mkdir /etc/certs

証明書を格納するディレクトリです

sudo mkdir /etc/private

秘密鍵を格納するディレクトリです

ディレクトリに証明書と秘密鍵を格納します。

  • SCPやSFTPでアップロードして対象ディレクトリに配置する
  • Let's Encryptなどで作成したファイルをそれぞれ対象ディレクトリにコピー/移動する

など、適当な方法を用います。(割と効率的なのがcatでファイル内容を開き、それを別サーバに貼り付ける方法です)

秘密鍵格納後、

sudo chmod 600 /etc/private/hoge.sample.com.key.202507

として、アクセス権を厳密にします。

上記、取得した*.example.comの証明書と秘密鍵を

  • /etc/certs (証明書)
  • /etc/private (秘密鍵)

に格納したとして手順を進めます。

証明書のシンボリックファイルを作成します。

cd /etc/certs && pwd

/etc/certsにいることを確認

sudo ln -sf hoge.sample.com.crt.202507 hoge.sample.com.crt
ls -l hoge.sample.com.crt

リンクの向き先がhoge.sample.com.crt.202507であることを確認します。

lrwxrwxrwx 1 root root     31  7月  2 14:35 hoge.sample.com.crt -> hoge.sample.com.crt.202507

秘密鍵のシンボリックファイルを作成します。

cd /etc/private && pwd

/etc/privateにいることを確認

sudo ln -sf hoge.sample.com.key.202507 hoge.sample.com.key
ls -l hoge.sample.com.key

リンクの向き先がhoge.sample.com.crt.202507であることを確認します。

後は、お使いのWebサーバに適用していきます。この方式であれば、

SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
# 秘密鍵を指定します

とすることで、.confファイルをいじることなく更新作業を行えます。

以下、Redmineでの設定例です。

https://atelier.ryza.jp/projects/zettel/knowledgebase/articles/20

Page 3 of 53

Powered by WordPress & Theme by Anders Norén