昨今のセキュリティ情勢により、サーバ証明書の有効期限は短縮され続けています。
最終的には 有効期限が 47 日 まで短くなることが決まっています。
短縮のロードマップ
| 最大有効期間 |
| 現状 | 200日 |
| 2027年3月15日以降 | 100日 |
| 2029年3月15日以降 | 47日 |
ここまで期限が短くなると、手作業による証明書更新は現実的ではありません。
そのため、サーバ証明書の更新作業は 自動化 を前提とした運用に移行する必要があります。 早いうちに移行の準備を進めるようにしてください。
自動化は大きく分けて 2つ の方法と 2つ の申請先があります。
2つの方法について (HTTP-01 チャレンジ と DNS-01 チャレンジ)
２つの方法とは、HTTP-01 チャレンジ と DNS-01 チャレンジの２つです。
一般的には HTTP-01 チャレンジのほうが設定難易度が低く、導入しやすい方法です。
ただし、どちらを選ぶべきかは サーバの役割・公開範囲・ネットワーク構成 によって変わります。
それぞれを選ぶ大まかな基準は以下の通りです。
- HTTP-01 チャレンジを選べるケース
- 大学外部に公開している Web サーバ
- 80 番ポートを外部に開けられるサーバ
- .well-known/acme-challenge/ を返せる Web サーバが動いている
- Web サーバのほとんどがこれに該当します。
- DNS-01 チャレンジを選ぶべきケース
- 学内限定サービス
- ロードバランサーや CDN を挟んでいる
- 学外に80を公開できない（機能が無い、セキュリティ上等）
- 注意：クラウドでサーバを借りている場合
クラウド環境では、証明書の扱いがサービスや業者によって異なります。
- AWS などの大手：証明書サービス（ACM）が自動更新を肩代わり
- 一般的な VPS：HTTP-01 チャレンジが使えるかどうかを確認
クラウド利用者は、そのクラウドがどのように証明書更新をサポートしているかを確認してから契約してください。
2つの申請先(Let’s Encript と NII )
サーバ証明書を自動で更新するための申請先も複数あります。山形大学で利用できる申請先のうち、Let’s Encript と NII について簡単に紹介させていただきます。
なお、クラウドの場合はこれらを使える場合もありますし、クラウド独自の方法になる場合もあります。
- 1. NII（UPKI）ルート【推奨：公式・高信頼】
- 特徴：大学の名前が証明書に刻まれる「公式な証明書（組織認証型）」です。
- メリット：学外の一般利用者や学生がアクセスする「公式WEBサイト」や「教務システム」に最適です。セキュリティ監査も問題なくクリアできます。
- 注意点：事前に学内窓口から「認証用のキー（KID/HMAC）」を発行してもらう初期設定が必要です。また、ワイルドカード（*）は使えません。
- Let's Encrypt ルート【手軽：検証・学内向け】
- ・特徴：世界中で使われている、誰でも無料で即座に発行できる暗号化証明書です。
- ・メリット：事前申請が一切不要で、コマンド一つで今すぐ利用できます。ワイルドカードも使えます。
- ・注意点：組織名（大学名）の証明は載りません。また、大学公式ドメイン（ac.jp）以外の独自ドメインでも発行できてしまうため、公的な信頼性はNIIより低くなります。
申請先についてはどちらも問題ありませんが、より公式なサービス、より信頼性のあるサービスを行う場合は NII を利用したほうがいいでしょう。
また、将来において組織証明のないサーバ証明書で運営されているサイトはサービスの制限など行われる可能性もありますので、
公式なサイトやデータのやり取りが必要なサイトはできるだけ NII を申請先として設定できるよう準備しましょう。
申請先は複数ありますが、設定していくにあたり、まず、Let's Encrypt に設定してみることをおススメします。
Let's Encrypt に設定できれば、他の申請先に変更するのはそれほど手間ではありません。
HTTP-01 チャレンジ と DNS-01 チャレンジ のどちらの方法を選択する場合でも同じです。
うまくいかない場合に原因を特定するための切り分けにもなりますので、まずはLet's Encryptに設定してみましょう。
HTTP-01 チャレンジの準備方法・実施方法（一例）
- DNS が正しくサーバを向いているか確認する
- Web サーバが .well-known/acme-challenge/ を返せる状態にする
- リダイレクト設定（HTTP→HTTPS）に注意
- .well-known/acme-challenge/ は HTTPS へリダイレクトしないようにする
- Certbot（または acme.sh）を導入する
- 既存証明書を置き換える形で「更新」する
- certbot certonly --webroot -w /var/www/html -d XXXXX.yamagata-u.ac.jp
( XXXXX は読み替えてください)
- 既存証明書があっても問題なく更新扱いになる
- 自動更新を設定する
- certbot renew を cron 等で定期実行設定する
- Webroot を指定する場合は --webroot -w /var/www/html を付ける（/var/www/htmlは適宜読み替え）
- 更新を行う（動作確認）
- certbot renew --dry-run でテスト
- Web サーバの設定ファイルが Certbot の証明書パスを参照しているか確認
- 更新後に Web サーバを reload する設定も必要に応じて追加
その後、自動実行のスケジュールに合わせて証明書が更新されるようになりますが、
念のため、更新スケジュールは少し早めにして、更新されたかをブラウザなどで確認するようにしてください。
絶対に更新に成功するとは限りませんので、失敗している場合は手動で処理してください。
この場合の手動は上記コマンドになります。
[an error occurred while processing this directive]
Linux での設定方法（１例）
あくまで１例です。方法は複数あります。また、すべてが同じ方法でうまくいくとは限りません。
適宜、うまくいかない部分などは自分で調べたり、保守業者と相談してください。
[an error occurred while processing this directive]
Windows での設定方法（１例）
あくまで１例です。方法は複数あります。また、すべてが同じ方法でうまくいくとは限りません。
適宜、うまくいかない部分などは自分で調べたり、保守業者と相談してください。
[an error occurred while processing this directive]
[an error occurred while processing this directive]
NII / UPKI ACME への切り替え
cmd (コマンドプロンプト)、あるいはshare point から 以下のコマンドを打つ。
wacs.exe ^
--baseuri "https://secomtrust-acme.com" ^
--accepttos ^
--emailaddress "【サーバ管理者のメールアドレス】" ^
--eab-key-identifier "【NIIから取得したKID】" ^
--eab-key "【NIIから取得したHMAC Key】"
※PowerShellの場合は ^ を ` に変更するか、改行せずに1行で入力してください
