タグ: SSL

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 日です。

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

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

Let’s Encrypt仕様変更によるSSL Staplingの無効化

新たなSSL証明書を導入したサーバにて、以下のエラーを確認。こちらの解決のメモです。

前提

  • Ubuntu 24.04
  • Apache 2.4
  • Let's Encryptによるワイルドカード証明書を発行

エラー内容

サイトのエラーログに以下を発見しました。

[Thu May 22 14:03:51.270340 2025] [ssl:error] [pid 929:tid 929] AH02218: ssl_stapling_init_cert: no OCSP URI in certificate and no SSLStaplingForceURL set [subject: CN=*.ryza.jp / issuer: CN=E6,O=Let's Encrypt,C=US / serial: 058A8F3B6C32F08B41E5E56BEAD92451D34A / notbefore: May 21 12:08:57 2025 GMT / notafter: Aug 19 12:08:56 2025 GMT]
[Thu May 22 14:03:51.270358 2025] [ssl:error] [pid 929:tid 929] AH02604: Unable to configure certificate atelier.ryza.jp:443:0 for stapling 
  • 意味:
  • ApacheがSSL証明書 (CN=*.ryza.jp) のOCSP Staplingを初期化しようとしましたが、証明書内にOCSPレスポンダのURI(OCSP URI)が見つかりませんでした。また、Apacheの設定で SSLStaplingForceURL も指定されていません。
  • OCSP Staplingとは:
  • SSL証明書の失効状態を効率的に確認するための仕組みです。ウェブサーバーが事前にCA(認証局)に問い合わせて証明書の有効性を確認し、その応答(OCSPレスポンス)を証明書と一緒にクライアントに提供することで、クライアント側の確認負荷を軽減し、表示速度を向上させます。

なお、Apacheの.confファイルには以下の項目があります。

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

つまり、ApacheでSSL Stapling設定されているにもかかわらず、OCSPレスポンスが働いていないことを意味します。

状況確認

現行の証明書の状況

openssl x509 -in /path/to/your/certificate.pem -noout -ocsp_uri

結果は何もなし。証明書内にこれがないことで、先のエラーが発生したようです。

過去にLet's Encryptで発行した証明書の状況

2024年9月に発行したLet's Encryptの証明書で

openssl x509 -in /path/to/your/certificate.pem.202409 -noout -ocsp_uri

を実施したところ、http://e6.o.lencr.orgと返ってきました。

導き出される状況

  • 証明書発行時に何らかのエラーが発生して、このURIが欠落した
  • 筆者は他に複数のドメインを利用し、いずれもLet's Encryptで証明書を発行しています。1つだけならいざ知らず、現行全てのドメインでの証明書でこのURLが欠落しているのは一時的なエラーではないと考えました。

そこで、もう一つの可能性として「Let's Encryptの仕様が変わったのでは?」と情報を探していきます。

答えを発見

Removing OCSP URLs from Certificates from Let's Encrypt

Let’s Encrypt will be removing OCSP URLs from certificates on May 7, 2025 as part of our plan to drop OCSP support and instead support certificate revocation information exclusively via CRLs.
Let's Encryptは、2025年5月7日にOCSPのサポートを停止し、代わりにCRLを介してのみ証明書の失効情報をサポートする計画の一環として、証明書からOCSP URLを削除します。

状況そのもののアナウンスを見つけました。この、OCSPのURLが消えた証明書は、いずれも、2025年5月18日以降に発行したものです。完全に時期的に一致。

対処

ここが分かれば、後は設定変更です。Ubuntuサーバで設定を変更します。

  • 設定ファイルバックアップ
sudo cp -pi /etc/apache2/sites-available/virutal.conf /path/to/backup/directory/virutal.conf.$(date +%Y%m%d)

設定ファイルは自分の環境に合わせます。任意のバックアップディレクトリを指定します。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/virutal.conf.$(date +%Y%m%d) /etc/apache2/sites-available/virutal.conf

差分がなければバックアップ完了です。

  • ファイル編集

任意の方法で(要管理者権限)以下のように編集します。

# 2025年5月のLet's Encryptの方針によりOCSPが廃止されたため
SSLUseStapling Off
#SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
  • 編集確認
diff -u /path/to/backup/directory/virutal.conf.$(date +%Y%m%d) /etc/apache2/sites-available/virutal.conf
-SSLUseStapling On
-SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
+# 2025年5月のLet's Encryptの方針によりOCSPが廃止されたため
+SSLUseStapling Off
+#SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動前確認
systemctl status apache2.service

active(running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service

※reloadより確実なrestartを採用しています

  • Apache再起動後確認
systemctl status apache2.service

active(running)を確認します。

修正確認

設定を反映させたサイトを適当に閲覧し、エラーログにて、冒頭のエラーがないことを確認しました。

サイトのSSL強化。(HSTSプリロード)

概要

サイトのセキュリティを高めるため、HSTSプリロードを設定したときのメモとなります。

環境

  • OS: Ubuntu 20.04
  • Apache 2.4系
  • Let's Encryptで取得した証明書を利用

前提条件

  1. インターネット上に公開されたサイトであること。(非ローカル環境)
  2. 公開するWebサイトドメイン全てに適切な証明書が設定されていること。
  3. Webサーバの設定で、httpアクセス全てをhttpsに変換する設定になっていること。
  4. 必要なモジュール(header、SSL等)がインストールされていること。

ここでは、hoge.example.com というサイトに対してHSTSプリロードを設定します。

注意点

  • サブドメイン全てに対して適用されます。(hoge.example.comの場合はwww.example.comはもちろん、example.comも対象となることを注意してください)
  • https化されていないサイトに対してもhttps接続を強制します。つまり、他にhttps化されていないシステムに対してもです。
  • プリロードリストに登録された場合、解除はとても難しくなります。相応の運用が試されることに注意してください。

さっくりとした手順

  1. HSTSを有効にします。
  2. httpdサービスを再起動します。
  3. HSTSサイトにドメインを登録します。

実施手順

apacheのバーチャルサイトファイルを修正します。

  • 修正後のファイル

※ドメインやDocumentRoot等は書き換えてください。また、サブドメインごとに複数のサイトがある場合、その全てを修正します。

<VirtualHost _default_:80>
servername hoge.example.com
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost _default_:443>
    servername hoge.example.com
    ErrorLog /var/log/apache/error.log
    CustomLog /var/log/apache/access.log combined

DocumentRoot /var/www/html/hoge

    <Directory /var/www/html/hoge>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

  SSLEngine on
    Protocols h2 http/1.1
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

SSLCertificateFile /etc/certs/hoge.example.com.crt
SSLCertificateKeyFile /etc/private/hoge.example.com.key

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off
  • 主な差分
-    Header always set Strict-Transport-Security "max-age=63072000"
+    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

-SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
+SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
  • HSTSのプリロードを有効化しています。
  • ついでに弱いSSL(TLSv1.2)を無効化します。

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

sudo apache2ctl configtest
# Syntax OKを確認します
sudo systemctl restart apache2.service

systemctl satus apache2.service
# active(running)を確認します。

HSTSプリロードサイトへの登録

  1. https://hstspreload.org/ にアクセスします。
  2. 上記で設定したドメイン名を入力して登録を進めていきます。(サブドメインは含みません)
  3. エラーがなければStatus: laplacemine.com is pending submission to the preload list.と表示されます。
  4. 2~3週間ほど待って正式に登録されるのを待ちます。

設定確認

  1. https://www.ssllabs.com/ssltest にアクセスします。
  2. HSTSを設定したサイトのドメイン名を入力して診断します。
  3. Strict Transport Security (HSTS) が「YEえs」となっていれば成功です。

Let’s Encryptの証明書整合でハマったこと。(ECDSA方式での整合性確認)

概要

更新サイクルが3ヶ月と短いものの、無料で利用できるということで愛用しているLet's Encrypt。
デフォルトの暗号化形式がRSAからECDSA方式に変わったようで確認方法でハマりました。

なんとか解決したのでメモを残します。

従来の確認方法

RSA方式での証明書は、以下の

openssl x509 -in /etc/certs/hoge.example.com.crt -noout -modulus | md5sum
# SSL証明書ファイル

openssl rsa -in /etc/private/hoge.example.com.key -noout -modulus | md5sum
# 秘密鍵ファイル

を実行し、それぞれのハッシュ値が合致していることで証明書と秘密鍵の整合性の確認を取ることができています。

ECDSA方式に変わったことでの問題

2023年4月時点で、Let's Encryptのデフォルト暗号化形式がRSA→ECDSA方式に変わっていました。

openssl rsa -in /etc/private/hoge.example.com.key -noout -modulus | md5sum
# 秘密鍵ファイル

を実行すると

139945929635648:error:0607907F:digital envelope routines:EVP_PKEY_get0_RSA:expecting an rsa key:crypto/evp/p_lib.c:469:

といったエラーが出ます。

これでは証明書と秘密鍵の整合性が確認できません。

しばらくGoogleと格闘し、なんとか解決策を見つけました。

https://security.stackexchange.com/questions/73127/how-can-you-check-if-a-private-key-and-certificate-match-in-openssl-with-ecdsa

ECDSA方式でも証明書と秘密鍵の整合性が確認できるコマンド

まず、鍵がECDSA方式であることを確認。

  • 確認コマンド
openssl ec -in /etc/private/hoge.example.com.key -text -noout
# 秘密鍵のパスを指定します
  • 確認結果
(略)
ASN1 OID: prime256v1
NIST CURVE: P-256
# 上記が表示されればECDSA方式であると確認できます。

次に、以下のようにして公開鍵を抽出してハッシュ値を割り出します。

openssl x509 -pubkey -in /etc/certs/hoge.example.com.crt -noout | openssl md5
(stdin)= ハッシュ値
# SSL証明書ファイル

openssl pkey -pubout -in /etc/private/hoge.example.com.key | openssl md5
(stdin)= ハッシュ値
# 秘密鍵ファイル

### 2つのハッシュ値が合っていれば証明書と秘密鍵の整合性は取れています

以上、ECDSA方式でも整合性を確認することができました。

余談

この、「鍵を用いて鍵を取り出す」って、『ライザのアトリエ3』で無垢の鍵から秘密の鍵を抽出しているようだなと益体もないことが脳裏をよぎりました。

homebrewを用いないUbuntuへのmkcertのインストール。

前回、homebrewによるローカル証明書(mkcert)を見つけましたが、それよりも楽な方法がありましたので、メモとして残します。

actix-webでSSL/TLS通信をしてみたよ

https://qiita.com/yoshiyasu1111/items/f22a5fb640651fd22b6c

環境はUbuntu20.04です。

必要パッケージをインストール

apt install libnss3-tools

インストール

curl -s https://api.github.com/repos/FiloSottile/mkcert/releases/latest | grep browser_download_url | grep linux-amd64 | cut -d '"' -f 4 | wget -qi - \
    && mv mkcert-v*-linux-amd64 mkcert \
    && chmod a+x mkcert \
    && mv mkcert /usr/local/bin/

ローカル認証局作成

 mkcert -install

これにより、管理者ユーザでもmkcertコマンドを使えるようになったのが大きいです。

ローカルredmineのSSL化。-ローカル証明書のインストールと常時SSL化-

この記事の続きです。

ここでは、mkcertで作成したローカル証明書をredmineサーバに入れておきます。

また、

  • httpを強制的にhttpsにリダイレクト
  • http://ip or DNS名 のアクセスをhttps://ip or DNS名/redmineへとリダイレクトする

設定も同時に入れ込みます。

redmineサーバ上での設定

必要なモジュールの有効化

a2enmod ssl
a2enmod rewrite
systemctl restart apache2
ss -lntp
# 443ポートがLISTENされていることを確認します

証明書ペアの格納

mkdir /etc/certs/
mkdir /etc/private/

その後、

/etc/certs → SSL証明書

  • corn.wall.crt.202204

/etc/private/ → 秘密鍵

  • corn.wall.key.202204

をそれぞれ格納します。

証明書ペアのシンボリックリンク化

後々のメンテナンスを考えて、証明書をシンボリックリンク化します。

cd /etc/certs/
ln -s corn.wall.crt.202204  corn.wall.crt
cd /etc/private/
ln -s corn.wall.key.202204 corn.wall.key

Virtualファイル記載

cd /etc/apahce2/site-available/
cp -pi redmine.conf /path/to/backup/redmine.conf.org
vi redmine.conf
redmine.confの内容
<VirtualHost _default_:80>
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
        #http通信を強制的にhttpsにリダイレクト
</VirtualHost>

<VirtualHost _default_:443>
  SSLEngine on
    SSLProtocol All -SSLv2 -SSLv3  -TLSv1
    SSLCertificateFile /etc/certs/corn.wall.crt
    # 証明書
    SSLCertificateKeyFile /etc/private/corn.wall.key
    # 秘密鍵

        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^penzance\.corn\.wall
        RewriteRule ^/$ https://penzance.corn.wall/redmine/ [R]
        # https://penzance.corn.wallへのアクセスをhttps://penzance.corn.wall/redmine/にリダイレクト

Alias /redmine /var/lib/redmine/public
CustomLog /var/log/redmine/access.log combined
ErrorLog /var/log/redmine/error.log
<Location /redmine>
PassengerBaseURI /redmine
PassengerAppRoot /var/lib/redmine
Require all granted
</Location>

</VirtualHost>

設定反映

apache2ctl configtest
# SyntaxOKを確認
systemctl restart apache2

再起動後、

  • redmineの通信がhttpsで行えること
  • ホスト名でアクセスしても/redmine/に移動すること

を確認しました。

補足とまとめ

  • セキュリティソフトによっては、このローカル認証局を「信頼できない」としてブロックする場合があります。その時はその設定を解除します。
  • また、mkcertsは開発用途なので外に出ていけないローカル環境での運用が前提です。
  • そのためか証明書の有効期限は3ヶ月。この運用をもっと楽にするのが今後の目標です

ローカルredmineのSSL化。-mkcertのインストール-

また、やりたいことに一歩近づきました。

  • 外に出ていけないローカルドメインでもSSL通信はしたい
  • 自己証明書と違った形でSSLを発行したい

という希望を求めていたら、「mkcert」なるものを発見したので、導入してみました。

redmineのSSL化

homebrewのインストール(検証機で実施する)

参考:
https://tdomy.com/2021/12/how-to-install-homebrew-on-ubuntu/

必要パッケージ取得

rootでは実行しないこと

sudo aptitude install libnss3-tools git curl

homebrewインストール

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
test -d ~/.linuxbrew && eval "$(~/.linuxbrew/bin/brew shellenv)"
test -d /home/linuxbrew/.linuxbrew && eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
test -r ~/.bash_profile && echo "eval \"\$($(brew --prefix)/bin/brew shellenv)\"" >>~/.bash_profile
echo "eval \"\$($(brew --prefix)/bin/brew shellenv)\"" >>~/.profile
brew --version
brew install hello
hello
brew uninstall hello

mkcertインストール

https://www.hivelocity.co.jp/blog/46149/

brew install mkcert
mkcert -install
mkcert -CAROOT
# ~/.local/share/mkcert配下にルート証明書とルート秘密鍵を確認
cd ~/.local/share/mkcert

mkcertで証明書発行

ここでは、自宅redmineに用いている

penzance.corn.wall

の証明書を発行します。

mkcert -key-file corn.wall.key.202204 -cert-file corn.wall.crt.202204 corn.wall penzance.corn.wall "*.corn.wall" 
openssl x509 -text -noout -in ./corn.wall.crt.202204 |grep DNS
# DNS:corn.wall, DNS:penzance.corn.wall, DNS:*.corn.wall と、入力したDNS名があることを確認します

次のエントリーでは、redmineにSSLを入れ込んでいきます。

Powered by WordPress & Theme by Anders Norén