SSL証明書の有効期間47日化はいつから？短縮スケジュールと対応手順

更新は年に1回、カレンダーに入れておけば回る。SSL証明書の運用は、長くそういう作業でした。その前提が変わります。公開されているWebサイト向けのSSL/TLS証明書は、最大有効期間が段階的に短縮されます。最終的な上限は47日、適用は2029年3月15日から（いわゆる「47日ルール」）。ただし、この短縮はすでに始まっています。2026年3月15日から上限200日が適用済みで、次の関門は2027年3月15日の100日です。

「うちはACMで自動更新にしてあるので影響はない」——そう言える構成もあります。では、その「自動更新」が指しているのは、証明書が新しく発行されることでしょうか。それとも、サービスが新しい証明書で応答することでしょうか。この2つのあいだには、サーバー上の証明書ファイルが入れ替わる、という段階がもう1つあります。①証明書が新しく発行される ②サーバー上のファイルが入れ替わる ③サービスが新しい証明書で応答する——この3つは同じ言葉で語られがちですが、どこまでが自動になるかは構成で決まります。

一方、ACMを使っていない構成——他社のCA（認証局）で取得し、CSRを発行して毎回サーバーに手作業で設置している場合——も、同じ短縮の影響を受けます。

この記事で扱うのは2つだけ。いつから何日になるのかと、自社の証明書のどれが対象で、どれが手当てを必要とするのか。後者は9つの区分に振り分ける形にしました。

※本記事は2026年8月12日時点の各一次情報にもとづきます。適用日・仕様・料金はいずれも変更されうるため、実際の判断は記事末の出典で最新の内容をご確認ください。証明書そのものの仕組み、ドメイン認証（DV）・組織認証・EV認証の違い、ACMの基本的な使い方は、AWS ACMで無料SSLはどこまで使える？（証明書の種類とACMの基礎）で扱っています。

SSL証明書の有効期間はいつから47日になるのか——短縮はすでに始まっている

短縮の背景と、決めているのは誰で、いつから何日になるのか。この章で押さえるのは、その2つです。

公開的に信頼されるTLSサーバー証明書の要件は、CA/Browser Forum という業界団体の「Baseline Requirements」で定められています。有効期間の上限を段階的に引き下げる改定は、2025年4月11日に可決された Ballot SC081v3 によるもので、上限398日から47日までを3段階で下げていく内容です。

現行の Baseline Requirements（v2.2.9・2026年8月6日発効）§1.2.2 では、適用日と日数が次のように定められています。

公開TLSサーバー証明書の有効期間・検証データ再利用期間の短縮スケジュール（2026年8月12日時点）

適用開始日	有効期間の上限	検証データの再利用期間
2026年3月15日	200日	200日	← 2026年8月12日時点はここ（適用済み）
2027年3月15日	100日	100日
2029年3月15日	47日	10日

出典: CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates v2.2.9 §1.2.2 Relevant Dates（2026年8月12日確認）／同 Ballot SC081v3（2025年4月11日可決）

この表は今後の改定で変わる可能性があります。最新の内容は上記の Baseline Requirements でご確認ください。

つまり200日への短縮はすでに終わっており、次の関門は2027年3月15日の100日です。改定前の上限は398日だったので、そこから見ればすでに半分以下になっています。

右列の「検証データの再利用期間」も同時に短くなります。ドメインの所有確認を一度おこなった結果を、次の発行のときに使い回せる期間のことです。2029年3月15日以降は10日。ドメイン認証を先に済ませておいて、あとでまとめて発行するという段取りは、事実上できなくなります。証明書そのものの日数だけでなく、ここも同時に見ておきたいところです。

上限の日数と自社の証明書の日数は別の話——ACMは198日、Let’s Encryptは90日

最大有効期間はあくまで業界のルール上の天井で、実際に発行されるSSL証明書がその日数になっているとは限りません。

AWS Certificate Manager（ACM）の場合、パブリック証明書の有効期間は198日です。AWSは2026年2月18日に、既定の有効期間を395日から198日へ変更したことを公表しました。理由として挙げているのが、CA/Browser Forum が2026年3月15日から200日以下を求めている点です。

Let’s Encrypt は既定90日。加えて、6日間の短期証明書をオプトインで選ぶこともできます。他社のCAをご利用の場合は、そのCAの発行ポリシーによります。

同じ「短くなる」という話でも、出発点が198日なのか90日なのかで、増える手間の幅は変わります。最初に確認するのは1つ。自社の証明書が、実際に何日で発行されているかです。 上限の話と自社の運用の話は分けて把握します。ここを混ぜると、どこまで手当てが必要かが決まりません。

出典: AWS, ACM public certificate characteristics and limitations／AWS, ACM updates default certificate validity to comply with new guidelines（2026年2月18日）／ISRG, Let’s Encrypt FAQ

更新の回数はどこまで増えるのか

有効期間が短くなれば、更新の回数はその分だけ増えます。ただ、期限のぎりぎりに更新する運用は現実的ではありません。実際の回数は「1年÷有効期間」より多くなります。

回数を見積もる目安になるのが、Let’s Encrypt の公式FAQです。同FAQは90日の証明書について60日ごとの更新を推奨しています。有効期間の約3分の2の時点で更新する、という考え方ですね。これを残る2段階に当てはめると、こうなります。

有効期間の上限	約3分の2の時点	1年あたりの更新回数
100日（2027年3月15日から）	約67日ごと	約5.5回
47日（2029年3月15日から）	約31日ごと	約12回

※現在の200日なら約133日ごと・年約2.7回。この回数は、Let’s Encrypt の公式推奨（有効期間の約3分の2で更新）を各段階に当てはめた試算です。実際の間隔は運用方針や自動化の設定によって変わります。

出典: ISRG, Let’s Encrypt FAQ（Last updated: April 28, 2025・2026年8月12日確認）

数字そのものより、意味のほうが実務に効きます。年1回の想定で作られた手順書・更新カレンダー・引き継ぎ資料は、月1回の頻度には向いていません。 対象が1本なら回ります。実際にはドメイン数×設置先の数で効いてきます。

「自動更新」が指しているのはどこまでか——更新と配置は別に決まる

ここが実務でいちばん食い違いが出るところです。ACMの「マネージド更新」は、条件によって対象になるかどうかが変わります。そして更新されることと、新しい証明書が実際に使われることは、別に決まります。

AWSの公式ドキュメントを整理すると、次の4通りになります。

自社の状態	ACMが証明書を更新するか	新しい証明書が使われるまで自動か
ALB・CloudFront・API Gateway などACM統合サービスに紐づけている	する	自動（更新と配置の両方が自動になる）
ACMからエクスポートして自社のサーバーに置いている	する（発行後または前回更新後にエクスポート済みであれば対象）	自動ではない（ダウンロードと配置は利用者側の処理）
他社CAで取得した証明書をACMにインポートした	しない（インポートした証明書は対象外）	—
ACMEで発行した	ACMのマネージド更新は適用されない（ACMEクライアントが更新する）	ACMEクライアントの設定による

補足が2点あります。

ひとつは検証方法です。ACMのマネージド更新が自動で走るのはDNS検証を使っている場合で、Eメール検証の場合は期限が近づくと通知が送られる形になります。

もうひとつはエクスポート運用です。AWSのFAQには「ACMはエクスポートされた証明書を更新し、利用者側の自動化コードがそれをダウンロードして配置できるようにする」と書かれています。つまり更新されたことと、サーバー上のファイルが置き換わったことは同じではありません。逆に、更新と配置の両方を自動にできるのはACM統合サービスと組み合わせた場合だ、という記述もあります。

「ACMなら自動更新される」という理解は、証明書が新しく発行されるところまでは正しいものです。そのうえで、新しい証明書がサービスに反映されるまで自動になるかどうかは、上の表のどこに当てはまるかで変わります。ここを分ければ、以降の判断は単純になります。分けないままでは、対応が必要な範囲が確定しません。

出典: AWS, Managed certificate renewal in AWS Certificate Manager／AWS, ACM certificate automation（ACME）／AWS, AWS Certificate Manager FAQs（いずれも2026年8月12日確認）

有効期間が短くなると、運用の何が変わるのか——作業回数・取りこぼし・課金回数

有効期間が短縮されること自体は、セキュリティの考え方としては筋の通った変更です。鍵が漏れていたり古い暗号方式が使われていたりする証明書が長く生き残らないほうがよい、という考え方ですね。

一方で、手元の運用にははっきりと3つの影響が出ます。ここで挙げるのは、いまの本数と構成から見積もれるものだけです。

年1回の想定で作った手順は、月1回には向かない

更新そのものは、慣れていれば数分で終わる作業。長いのはその前後です。対象の確認、関係者への連絡、切り替えのタイミング調整、切り替え後の疎通確認。この一連が1回分で、それが年1回から年12回へ近づいていきます。増えるのは作業時間だけではありません。証明書の期限と向き合う回数そのものが増えます。

年1回の作業には、年1回なりの設計がされています。カレンダーに登録しておく、手順書を見ながらやる、担当者が覚えている——どれも年1回なら成り立つやり方です。月1回になると、覚えている前提や、都度手順書を読む前提が崩れます。

そして影響は本数に比例します。ドメイン数と設置先の数を掛けた本数が、そのまま年間の作業回数に乗ります。10本あれば、単純計算でその10倍です。

「更新はできていた」のに古い証明書で応答していた、が起きる構成

先ほどの4通りのうち、エクスポート運用の行がここに当たります。

ACM側では新しい証明書が発行されている。管理画面で見れば期限も先に延びている。それでも、サーバー上に置いてある証明書ファイルは、前回エクスポートしたときのままです。ダウンロードと配置は利用者側の処理なので、そこが動いていなければ、外から見える証明書は古いままになります。

同じことは、自前でACMEクライアントを動かしている構成でも起きます。証明書ファイルは新しくなったのに、WebサーバーやLBの再読み込みが走っていない、という形です。

この取りこぼしが見つけにくいのは、確認するはずの画面が「問題なし」を示しているからです。 ACMの管理画面は正しく「更新済み」と表示しますし、期限も先に延びています。実際の証明書が古いままだと分かるのは、ブラウザや外部からアクセスしたときです。画面を確認した時点で作業が終わる——そうなりやすいのが、この構成のいちばん難しいところだと考えています。

更新の頻度が上がると、この種の取りこぼしが起きる機会も回数に比例して増えます。 年1回であれば、担当者が最後まで見届けるという運用でも成り立ちました。回数が増えるほど、見届ける前提は持ちません。

課金の回数が増える証明書がある

見落としやすいのがここ。ACMの料金はSSL証明書の種類によって課金の仕組みが違い、そのうち2つは「発行時」と「更新のたび」に課金されます。2026年8月12日時点のAWSの料金ページによると、内訳は次の3つです。

パブリック証明書（エクスポート不可・AWS統合サービスで使うもの） … 無料
エクスポート可能なパブリック証明書 … FQDN 1件あたり $7.00／ワイルドカード $79.00。発行時と、更新のたびに課金
ACME経由で発行する証明書 … 最初の1,000 FQDNまで1ドメインあたり $1.00（以降は段階的に低下）／ワイルドカードは最初の500件まで $5.00。発行時と、自動更新のたびに課金

出典: AWS, AWS Certificate Manager Pricing／AWS, AWS Certificate Manager FAQs（2026年8月12日確認）

課金が更新のたびに発生するなら、有効期間が短縮されるほど、同じ証明書でも年間の課金回数が増えることになります。ACMのパブリック証明書は現在198日で、有効期間の約3分の2で更新すると年約2.7回。47日になると年約12回。回数だけを見れば約4.4倍です。

金額の総額はここでは出しません。ドメイン数やワイルドカードの有無で変わりますし、料金自体も改定されます。押さえたいのは2点だけ。「無料だと思っていた証明書が、実は発行ごとに課金される種類だった」という取り違えが起きうること。そしてAWS統合サービスで使うパブリック証明書は無料であること。この2点が、次の選択肢の重みづけに直接効いてきます。

SSL証明書の更新を自動化する3つの選択肢——ACM・ACME・手作業の割り振り方

打ち手は3つ。ただし、どれか1つを全体に適用するものではありません。証明書ごとに割り振ります。 全部を自動化できる環境はまずないので、割り振りが前提です。

考える対象を減らす：更新も配置も自動になる構成へ寄せる

ALB・CloudFront・API Gateway でTLSを終端し、ACMの証明書を紐づける構成です。先ほどの4通りでいえば1行目に当たり、更新と配置の両方が自動になる唯一の型。しかも、この用途のパブリック証明書は無料です。

証明書のことを考える回数を減らすのは、手を抜くことではありません。考える対象を選ぶことです。寄せられるものを先に寄せてしまうほうが、残りに集中できます。

ただし条件が2つ。TLSを終端する場所が変わるため、構成の変更が伴います。クライアント証明書による相互認証が必要な場合や、アプリケーション側で証明書を直接扱っている場合など、寄せられない用途もあります。もう1つは検証方法で、ACMの証明書はDNS検証で取得しておくのが前提です（Eメール検証では自動更新にならず、通知が届く形になります）。

ACMEで自動化する：自社のサーバーに置き続ける場合

サーバー上でTLSを終端する構成を維持するなら、ACMEプロトコルによる自動化が選択肢になります。ACMEはRFC 8555で定義された仕様で、クライアントがサーバーと通信して証明書の取得と更新を自動でおこないます。Certbot や cert-manager といったクライアントが広く使われています。

AWS環境で使える選択肢としては、ACMのACME機能と Let’s Encrypt があります。2026年8月12日時点の主な違いは次のとおりです。

項目	ACM ACME	Let’s Encrypt
有効期間	45日	90日（6日間の短期証明書をオプトインで選択可）
認証レベル	ドメイン認証のみ	ドメイン認証のみ（組織認証・EV認証は提供なし）
発行元	Amazon Trust Services	ISRG
想定する設置先	利用者が管理するインフラ（オンプレミス、Kubernetes、ハイブリッド環境）	同様に自社管理のサーバー
秘密鍵	ACMEクライアントが生成・保持し、ACMは参照しない	クライアント側で生成・保持
対応クライアント	Certbot、cert-manager	Certbot ほか
発行の制御	管理者が発行できるドメインを事前に承認し、外部アカウント連携（EAB）の資格情報を配布する	発行数のレート制限（登録済みドメインあたり7日間で50枚など）
料金	最初の1,000 FQDNまで1ドメインあたり $1.00（発行時と自動更新のたび）	無料
AWS統合サービスへの紐づけ	不可	不可

出典: AWS, ACM certificate automation（ACME）／AWS, AWS Certificate Manager Pricing／ISRG, Let’s Encrypt FAQ／ISRG, Rate Limits（Last updated: August 5, 2026）（いずれも2026年8月12日確認）

選び分けの軸は3つです。

発行できるドメインを管理者側で統制したいか。 ACMのACME機能は、管理者が事前に承認したドメインに対してのみ発行できる仕組みで、IAMのロール設計に載せられます。発行の成否はCloudWatchのメトリクスとACMのコンソールで確認可能。誰がどのドメインの証明書を取れるかを分けたい組織では、この点が効いてきます。
無料で済ませたいか。 Let’s Encrypt は無料。ACMのACME機能はドメイン単位の課金が発生します。
どちらもドメイン認証のみである点をどう見るか。 組織認証やEV認証が求められている用途では、この2つの自動化には載りません（後述の区分Fに当たります）。

実務上の注意は2点。

ACMEで発行した証明書は、ALB・CloudFront・API Gateway に紐づけられません。サーバー側で使う前提の証明書です。
ワイルドカード証明書を使う場合、Let’s Encrypt ではDNS-01チャレンジが必須です。つまりDNSのレコードを自動で書き換える経路が必要になります。ACMのDNS検証も同じくDNSにレコードを置く方式なので、いずれにしてもDNSの管理権限が前提になります。DNSの管理体制についてはAmazon Route 53でドメイン管理を安全に運用する方法を、DNSに登録した内容を運用に使う話としてはメールセキュリティは「受信対策が9割」（SPF/DKIM/DMARCの実務ポイント）も参考になります。

手作業を続ける：いつまで持たせるかを決める

全部を自動化できる環境は多くありません。だから3つ目の選択肢は「手作業を残す」。これは消極的な選択ではなく、どこに手作業を残すかを決めるという設計判断です。

判断の材料になるのが、さきほどの更新回数の試算。対象の本数に、その段階での年間更新回数を掛けます。この数字を出すと、「いつまで手作業で持たせるか」を段階で切れるようになります。たとえば現在の200日（年約2.7回）は今の運用で吸収できても、2027年3月15日の100日（年約5.5回）はぎりぎり、2029年3月15日の47日（年約12回）は同じやり方では持たない——という切り方ができます。

手作業が悪いという話ではありません。回数が増えると、年1回を前提に組んだ設計が合わなくなる。それだけのことです。合わなくなる時期を先に把握しておけば、そこまでに間に合わせる計画を立てられます。

自社のSSL/TLS証明書のどれが対象か——9つの区分に振り分ける

ここからは手を動かす章です。自社の証明書を1件ずつ、9つの区分のどれかに入れていきます。1件でも振れれば、次に何をするかが具体的になります。なお、何から対策するかの優先順位づけについては、AWSでのWEBサービスに必要なセキュリティ対策（最低限やるべき順番と判断基準）も参考にしてください。

区分は9つ。ただし、覚える必要はありません。自動化に載るもの（A・B）／方式を見直すもの（C・D・E）／自動化に載らないもの（F・G）／今回の対象外（H）／担当を確かめるもの（I）、という並びです。

区分	該当する証明書・環境	短縮スケジュールへの対応
A	ALB・CloudFront・API Gateway に紐づけたACM証明書（DNS検証で取得）	更新と配置の両方が自動。証明書は無料。まずここに寄せられないかを検討する
B	自社管理のサーバーで、ACMEクライアント（Certbot・cert-manager など）を動かせる環境	ACMのACME機能または Let’s Encrypt で自動化する。ワイルドカードを使う場合はDNS-01が必要
C	ACMからエクスポートして自社のサーバーに置いている証明書	ACM側は更新するが、ダウンロードと配置の自動化は自前で用意する。なお2025年6月17日より前に作成したACMのパブリック証明書はエクスポートできない
D	他社CAで取得してACMにインポートした証明書	ACMのマネージド更新の対象外。更新の方式そのものを見直す対象
E	他社CAで取得し、ACMを通さずサーバーに手作業で設置している証明書（CSRを発行して申請し、届いた証明書を設置する形）	更新の方式そのものを見直す対象。1回あたりの手間が減らないため、回数の増加がそのまま作業量になる。影響がもっとも直線的に出る区分
F	組織認証（OV）・EV認証が求められている用途	ACMのACME機能と Let’s Encrypt はどちらもドメイン認証のみ。この2つの自動化には載らないため、別の手段を検討する
G	更新のたびにベンダーへ作業を依頼している／管理画面から手動で入れ替えている機器・アプライアンス	ACMEクライアントを動かせない構成にあたる。手作業が残る前提で、その段階の更新回数に耐えられるかを判断する
H	社内CA（プライベートCA）が発行した証明書、クライアント証明書	今回の短縮スケジュールの対象は「公開的に信頼されるTLSサーバー証明書」なので対象外。ただし更新と失効の運用そのものは残る
I	外部の委託先・SaaS が保有・管理している証明書（例: MA・メール配信のトラッキング用サブドメイン、採用サイト、ヘルプセンター、ECカート・決済など）	更新を誰が担当しているかを確認する。確認先が分からない場合は、契約書や保守範囲の記載を見る／取得元CAの管理画面で所有者を確認するあたりから当たれる

出典: CA/Browser Forum, Baseline Requirements v2.2.9（区分Hの範囲）／AWS, Managed certificate renewal in AWS Certificate Manager（区分A・C・D）／AWS, ACM certificate automation（区分B・F）／AWS, Export an ACM public certificate（区分C）／ISRG, Let’s Encrypt FAQ（区分B・F）（いずれも2026年8月12日確認）

区分Fと区分Gは、技術的な条件ではなくいまの運用の状態で振り分けられます。区分Fは「その要件を決めているのが誰か」——取引先の指定、入札条件、社内規程のいずれかで組織認証やEV認証が求められているなら区分Fです。区分Gは「更新のときに自分でコマンドを打っているか、それ以外か」——ベンダーへの作業依頼や管理画面での手入力が必要なら区分Gにあたります。

区分Hについて1点補足します。対象外なのは最大有効期間のルールであって、運用が楽になるわけではありません。社内CAの証明書にも有効期限があり、失効の管理も必要です。「対象外だから何もしなくてよい」ではなく、「今回のスケジュールに合わせる必要はない」という意味で読んでください。

一覧に持たせる6つの列と、いちばん埋まらない列

区分の説明はここまでです。あとは自社のSSL証明書を1件ずつ当てるだけ——なのですが、当てるには先に一覧が要ります。証明書管理の出発点になる部分で、実務で使えるものにするには次の6列があると足ります。

列	入れる内容
1. ドメイン／FQDN	ワイルドカードやマルチドメインかどうかも分かる形で
2. 置き場所（複数ある場合は全部書く）	AWSのどのサービスか／どのサーバーか／どの機器か／委託先か。同じ証明書を複数台に置いているなら、その台数分すべて書く
3. 取得元	ACM／Let’s Encrypt／他社CA／社内CA
4. 認証レベル	ドメイン認証／組織認証／EV認証
5. 現在の有効期間と次回の有効期限	何日の証明書か、有効期限はいつか
6. 更新の担当	誰が更新しているか（人／仕組みの名前）。「別部署が管理している」「制作会社が取得している」も、担当が決まっている状態です

2列目を台数分すべて書くのは、1行1証明書で書き切ると「1台だけ更新漏れ」が一覧に現れないからです。

一覧に必要な列は、ドメインと期限だけではありません。経験上、いちばん埋まらないのは6列目の「更新の担当」。とくに区分GとIに当たる行で空欄になりやすくなります。

補足しておくと、空欄が見つかることは棚卸しが失敗したサインではなく、棚卸しの成果です。 担当が決まっていない行を先に見つけておくことが、この作業の目的のひとつだと考えてください。

自動化を自社で回すなら、設計が必要な5項目

最後にもう1つだけ。区分AとBに寄せると決めたあと、実際に回すために決めておく項目が5つあります。ツールを入れれば終わり、とはならない部分です。

対象と方式を決める — どの証明書を、どの方式（ACM統合／ACM ACME／Let’s Encrypt）に載せるか。区分表がそのまま割り振り表になります。
更新後に何を再読み込みするかを決める — 証明書ファイルが新しくなったあと、WebサーバーやLB、アプリケーションのうち何を再起動・再読み込みするか。前章で挙げた「更新はできていたのに古い証明書で応答していた」は、ほぼこの項目の設計漏れで起きます。
失敗したときの動きを決める — 更新が失敗したら誰に通知が飛ぶか、前の証明書のまま動き続けられるか、やり直しの手順は何か。
展開の範囲と順番を決める — 1台で成功しても、残りの台数への展開は別の工数です。本数と順番を先に出しておきます。
有効期限を見る仕組みを決める — 何日前に気づくか、誰が見るか。自動化したあとも有効期限は見ます。自動化の枠に入っていない証明書（区分E・F・G・H・I）が残るからです。監視の設計そのものの考え方はAWS監視の基本と設計手順にまとめています。

この5項目と区分表が埋まれば、「対象はどれで、いつまでに、誰が」の3つが揃います。2027年3月15日（100日）と2029年3月15日（47日）という残る2つの期限に対して、それぞれ何を終わらせておくかを並べれば、対応の計画になります。

まとめ

押さえるのは3点です。

1つ目は、短縮がすでに始まっていること。 47日は2029年3月15日からですが、200日は2026年3月15日から適用済みで、次の関門は2027年3月15日の100日です。逆算の起点は2029年ではありません。

2つ目は、「自動更新」と「新しい証明書が使われること」は別に決まるということ。 ACM統合サービスに紐づけている場合は両方が自動になります。エクスポートして自社のサーバーに置いている場合は、配置の部分が利用者側の処理として残ります。インポートした証明書はマネージド更新の対象外です。そしてACMをまったく通していない構成も、当然ながら同じ短縮の影響を受けます。ここを分けて把握すると、対応が必要な範囲がはっきりします。

3つ目は、今日できるのは区分を振るところまでだということ。 一覧に6つの列（ドメイン／置き場所／取得元／認証レベル／有効期間と次回の有効期限／更新の担当）を用意して、A〜Iの区分を1件ずつ当てる。それができれば「対象はどれで、いつまでに、誰が」の3つが揃います。この3つを聞かれる相手は、社内だけとは限りません。委託元やエンド顧客から問われる場合もあります。

自動化の設計まで進んだあとも、有効期限を見る仕組みは残ります。自動化の枠に入らないSSL/TLS証明書が残るからです。区分を振る作業は、その残りがどれなのかを先に把握する作業でもあります。

一覧を作って区分を振るところまでは、社内の情報だけで進められます。

止まりやすいのはその先です。組織認証が求められている用途（区分F）、更新のたびにベンダーへ依頼している機器（区分G）、誰が管理しているか分からない委託先の分（区分I）。この3つは、自動化の枠に入らないまま手作業として残ります。どう扱うかは、構成と契約の形ごとに答えが変わります。

Cloud Assist の AWS導入支援サービスでは、SSL証明書の取得と更新管理、サーバーへのインストールを承っています。区分表を埋めたあとで、方式の選び方から見たい場合の入口としてご覧ください。

一覧の作成が途中でも構いません。「この機器の分をどう扱うか」といった単発の相談から受けています。

▶　お問い合わせはこちら：https://cloudassist.jp/contact/　◀

出典

なお本記事は2026年8月12日時点の各一次情報にもとづきます。適用日・仕様・料金は変更されうるため、実際の判断は下記の出典で最新の内容をご確認ください。

CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates v2.2.9（2026年8月6日発効）§1.2.2 Relevant Dates — https://cabforum.org/working-groups/server/baseline-requirements/requirements/ （2026年8月12日確認）
CA/Browser Forum, Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods（2025年4月11日可決） — https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ （2026年8月12日確認）
AWS, ACME certificate automation（AWS Certificate Manager ユーザーガイド） — https://docs.aws.amazon.com/acm/latest/userguide/acm-acme.html （2026年8月12日確認）
AWS, Managed certificate renewal in AWS Certificate Manager — https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html （2026年8月12日確認）
AWS, AWS Certificate Manager public certificate characteristics and limitations — https://docs.aws.amazon.com/acm/latest/userguide/acm-certificate-characteristics.html （2026年8月12日確認）
AWS, Export an AWS Certificate Manager public certificate — https://docs.aws.amazon.com/acm/latest/userguide/export-public-certificate.html （2026年8月12日確認）
AWS, Renew ACM public certificates — https://docs.aws.amazon.com/acm/latest/userguide/renew-publicly-trusted.html （2026年8月12日確認）
AWS, AWS Certificate Manager FAQs — https://aws.amazon.com/certificate-manager/faqs/ （2026年8月12日確認）
AWS, AWS Certificate Manager Pricing — https://aws.amazon.com/certificate-manager/pricing/ （2026年8月12日確認）
AWS, AWS Certificate Manager updates default certificate validity to comply with new guidelines（2026年2月18日） — https://aws.amazon.com/about-aws/whats-new/2026/02/aws-certificate-manager-updates-default （2026年8月12日確認）
ISRG（Let’s Encrypt）, FAQ（Last updated: April 28, 2025） — https://letsencrypt.org/docs/faq/ （2026年8月12日確認）
ISRG（Let’s Encrypt）, Rate Limits（Last updated: August 5, 2026） — https://letsencrypt.org/docs/rate-limits/ （2026年8月12日確認）