久しぶりにサーバーの設定と運用プロセスの大幅な変更をやる羽目になっててんやわんや、な話です。
何かというと、この前、自前のサーバーのSSL/TLS証明書の期限切れが近づいたので、いつものように更新をしようとしたんです。httpsの認証に必要なアレです。
そしたら、なんかSSL/TLS証明書の有効期限が年単位ではなくなっていて。現状、新規発行の証明書の有効期限は200日が上限なんだとか。
どういう事なのかと調べてみると、世界共通のSSL/TLS証明書の仕様として、段階的に有効期限を短縮する事になっているんだそうで。
従来(2020年以降)は398日だったのが、2026年3月15日から200日になり、2027年3月15日に100日、最終的に2029年3月15日には47日まで短縮される事が決まっていると。今はその第一段階目というわけですね。
何それ困る。
いや思い返してみれば、数年前から複数年の証明書が発行不可能になっていたり、認証用サーバーの所在地域やベースの認証局そのものが変更になってたりと色々変化が起きている様子はあったのですが、運用の仕方自体を見直さなければならない程まで短縮されるとは認識していませんでした。半分くらい寝耳に水です。
ちなみに私のところでは、年に1回、メール認証で証明書を取得して、手動でサーバーに設置するやり方を採用していました。ルーチン化されているとはいえ相応に手間もかかるわけで、それが1.5ヶ月に1回となると、完全に破綻してしまいます。何より証明書の更新契約なんてそんな頻繁にやってられません。
いや、情報収集が出来ていない自分の落ち度と言われればその通りではあるんですが。
でもですね、実際問題として、サーバー管理を生業としているわけでもなく、普段はIT業界の外で仕事をしている個人に、こういう一般に広報周知されない特定の専門的技術領域の仕様変更のロードマップまで把握して抜かりなく事前に対応しろ、というのは無理があると思うし、把握出来てない人や対応が出来ない・遅れた人の事なんぞ知らん、というのは流石に酷いと思うのですよ。社会基盤の維持管理の進め方としてそのやり方はないんじゃないの、と。
そもそも期限を短縮する理由は、セキュリティ面の強化が主目的で、インシデント発生時の証明書差し替えの範囲限定・迅速化等が副次的な目的らしいですが、その説明では全ての証明書の有効期限短縮を強行する必要性を十分に立証出来ているとは言えないように思うのです。
セキュリティ強化が必要な理由であるところの暗号解読可能性については、量子コンピューティングが現実に脅威となる水準に達する見込みは依然として立っていないのだから理由にならないでしょう。というか量子コンピューティングが暗号解読を現実に実行出来るレベルになるなら、そもそも既存の計算困難性に拠って立つ暗号方式自体が原則無力化されるのだから、証明書(暗号鍵)の更新期間を短縮したところで無意味です。
証明書差し替えの範囲限定云々についても、インシデントの発生如何に関わらず全ての証明書を頻繁に差し替えさせるというのではどう見ても管理コストは逆に激増するし、本末転倒で対策になっていないと言うべきです。
とはいえ、愚痴を吐いても嘆いても仕方ない話だし、不満を抱えつつも対応する他ありません。というわけで慌てて情報収集。
まず世間一般の対応、その中心となる有料の証明書プロバイダーがどう対応しているのかというと、契約自体は年単位で、証明書のサーバーへの設置・更新を自動で行うヘルパープログラムに対応しているプラン等を用意している様子。概ね更新手続きを代行する形になるんでしょうか。しかし当然ながら想定する顧客は法人につき相応に高価であまりにオーバースペック、細々と運用している個人のサーバーにはとても採用出来ません。
どうしたものか、いっそwebサイトは廃止するか？等と思案しつつ色々調べてみると、私のような個人等への救済措置がありました。無償の認証機関がいつの間にか標準的な地位を確立していており、世の小規模サイトの大半はその証明書を利用しているそうで。
その名もLet's Encrypt。少々怪しげな名称とは裏腹に、多数の大手IT企業から支援を受けて標準の地位を確立しつつある、自由でセキュアなインターネットを支える一大組織です。
有料の認証機関発行の証明書と暗号等も含めた方式上は全く同じで、信頼性も十分。違いはただ一点、シール(アイコン)がない事だけです。サイトに貼れる**signとかいうマークです。どうでもいいですね。元々何の意味があるのか理解し難い要素でしたし。
ざっと調べて機能的には特に問題もなく、もうこれは大人しく世の流れに流されて、Let's Encryptに乗り換えるしかない、という判断の下、乗り換えてしまいました。
その作業は、全世界に広く普及させる事を主眼に置いているだけあって、基本的には簡単なものです。Let's Encryptは当然ながらおよそ想定される全てのサーバー構成に対応してもいます。
私のところでは単一ドメインで運用していて、OSにはubuntu server, webサーバーにはnginxを採用していますが、その場合の推奨される要件は以下の2点です。
1. snapが使える
2. 証明書取得時の認証用にport80(http)を開放する(全世界のIPからアクセス可)
これを満たせば、証明書取得・設定ツールをインストールして、コマンドを打つだけで証明書の取得及びwebサーバーへの証明書登録が出来るようになっています。なお認証にはDNSレコードを使用する方式等もありますが、あえてその方法を選ぶ理由は通常はないかと思います。
以下、私のところで使った方法、すなわちubuntuでnginxに証明書を設置する場合について記述します。
取得・設定ツールには複数ありますが、certbotが最もよく使われていて事実上標準的な地位にあるので、特殊な事情があるというのでなければこれを使う事が推奨されています。certbotは下記コマンドでsnapから取得します。(1の要件はこのためです。なんでもsnapでないと適切な管理が困難なのだとか。多分にセキュリティ面の都合でしょうか)
$ sudo snap install certbot
なお、apt版のcertbotがインストールされている場合は競合して不具合が出る可能性があるので事前にアンインストールしておく必要があるようです。
そして、ファイアウォール等でport80へのアクセスが制限されている場合はそれを解除します。特定の国や地域からのアクセスを遮断するgeoblock系のフィルタを導入している場合はこれも解除します。(特定の地域等をフィルタから外す、というような設定では対応出来ません。Let's Encryptでは複数の国・地域に分散設置されている認証用サーバーのIPや所在地等を一切公開しておらず、予告なく変更もする方針を明らかにしているからです。)
例えば、iptablesで設定するなら、次のようなコマンドでルールの1番目にport80へのアクセスは(地域等を問わず)無条件で通すよう設定すればよいでしょう。
$ sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
ufwしか使っていないのなら、
$ sudo ufw allow to any port 80
とか。
その上で、
$ sudo certbot --nginx
等として、プロンプトで対象ドメインの選択等の応答をすれば、証明書の取得及びnginxへのSSL証明書の設定(/etc/nginx/sites-available以下の更新)が実行されます。簡単ですね。
なおドメインを引数で指定する場合は、-dオプションを使います。
$ sudo certbot -d [ドメイン名(example.com等)] --nginx
なお、私の所ではこのコマンドは使っていません。というのも、対象のサーバーは元々nginxを使ってウェブサーバーとして運用していたので、当然SSL関連も含め設定には色々と手を入れていたのですが、certbotの自動設定でそれらが都合よくマージされるとは考えづらかったのです。仮に現状では良くても、将来的に問題が生じるかもしれませんしね。
なので、certbotでの処理は証明書を取得するだけに留め、取得した証明書のnginxへの設定については手動で設定ファイル(nginx.conf等)を書き換える方法を取りました。要するに、従来の認証局からの証明書取得からサーバーへの設置までの手続きをcertbotに入れ替えただけという事です。思うに、初めてwebサーバーを立ち上げるようなケース以外は、基本このやり方を採用するんじゃないでしょうか。
その(証明書だけを取得する)場合はcertonlyオプションを指定します。
$ sudo certbot certonly --nginx
取得された証明書は、(2026年9月現在のところ)以下の通りに保存されます。
証明書: /etc/letsencrypt/live/[ドメイン名]/fullchain.pem
秘密鍵: /etc/letsencrypt/live/[ドメイン名]/privkey.pem
nginxの設定を手動でする場合は、/etc/nginx/sites-available/以下の設定ファイルに上記証明書及び鍵ファイルのパスを書き込みます。(ssl_certificate及びssl_certificate_keyをそれぞれ書き換え)
証明書の取得・設置を終えたら、nginxを再起動します。
$ sudo systemctl restart nginx
以上で完了。
ufwやiptable等でportを開放した場合は、元に戻しておきます。
上記のiptablesコマンドでルール1を追加したのなら、次のようなコマンドでそのルール1を削除します。(iptablesを使うような人には釈迦に説法だろうとは思いますが、iptableの操作、特にルールの削除は間違えると大変な事になる可能性があるので、事前にsudo iptables -L --line-numbers等で削除するルール番号等が正しいかよく確認した上で実行すべきでしょう。)
$ sudo iptables -D INPUT 1
ufwなら開放したポートを閉じます。
$ sudo ufw deny to any port 80
これで後始末も終わり。
取得した証明書の有効期限は、現在のところ90日です。有効期限が近づいたらまたcertbotを動かして証明書を更新します。(portを閉じている場合はその都度開ける必要があります)
面倒ならcron等で自動起動するようスケジューリングしておけばいいのですが、port管理の問題等もあるので私のところではそこは手動でやる事にしています。面倒ですが仕方ない。常時全世界からアクセスOKにしてしまうとbotや不正アクセス試行の類が酷いことになるのでここは譲れないのです。
有効期限短縮のスケジュールに変わりがなければ、2029年3月15日までは90日サイクルでの更新でいい、という事になる筈ですが、全世界ほぼ全てのサーバーが対応を迫られる、しかもかなりドラスティックな変更なので、個々の証明書の有効期限は準備期間を設ける意味で2029年3月15日よりかなり前に短縮されるのではないかと思われます。またその時には更新プロセスを修正する必要があるでしょう。
そんな感じで。私のところは単一のサーバーの設定だけですが、それでも情報収集から既存プロセスへの適用可否等の検討やらはそれなりに手間で、疲れました。世の中のサーバー管理者の皆様の中には大規模なサーバー群のドメインと証明書の管理プロセスの見直しに頭を抱えている人も多数いるんでしょうね。ご愁傷さまです。
もっとも、それを専門とする事業者にとってはいい仕事の種になるのだろうし、むしろ歓迎している向きもそれなりにいるのかもしれませんが。零細個人としては、そういう業界の都合に巻き込まないで欲しいと思う次第です。やれやれ。
Posts
