複数サイトのSSL証明書を管理するには、サイトごとの有効期限だけでなく、「どの公開URLで、どの証明書が使われ、誰が更新し、誰が更新後の接続を確認するのか」を一つの台帳で整理することが重要です。ドメイン名と期限だけを並べた表では、更新担当者の不在、制作会社との責任分担、CDNとサーバーの証明書の違いなどに対応できない場合があります。
例えば会社サイト・会員サイト・オンラインショップを別々のサーバーで運用している場合、証明書の発行元や自動更新の方式、更新担当者が異なることがあります。さらに一つの証明書を複数のホスト名で共用していたり、CDNとオリジンサーバーで別の証明書を使っていたりすると、「サイト数＝証明書数」とは限りません。管理する対象の関係を整理することが、一元管理の出発点です。
この記事では、すぐに使える証明書管理台帳の項目と記入例、更新責任者・作業担当者・代行者・確認担当者の分け方、新規サイトの登録から更新完了・担当交代までの運用例を紹介します。期限監視の通知日数や具体的なOpenSSLコマンドは、SSL証明書の期限監視と有効期限の確認方法の記事に分け、今回は複数サイトを管理し続ける仕組みを中心に説明します。
複数サイトのSSL証明書を一元管理する必要性
会社が管理するWebサイトが増えるほど、証明書の更新時期や担当者は分散しやすくなります。個々のサーバーで自動更新が動いていても、会社全体で誰が責任を持つかは別の問題です。
「期限を知っている人」だけに依存しない
担当者のメールに更新通知が届く運用では、その人が異動・退職・長期休暇になった際に、別の人が状況を把握できない可能性があります。また、サイトごとに管理画面が異なると、どこにログインすべきかを調べるところから作業が始まります。
一元管理では、担当者本人の記憶ではなく、会社や組織として参照できる記録に「対象」「期限」「更新方法」「責任者」「連絡先」「確認履歴」を残します。更新作業の担当者が変わっても、次の担当者が必要な情報を追える状態を目指します。
管理対象は証明書の数だけではない
例えば example.com と www.example.com が一枚のSAN証明書を利用することがあります。一方で shop.example.com は外部のEC基盤が独自に証明書を管理するかもしれません。さらにCDNを使えば、利用者から見える証明書とオリジン用証明書が分かれる場合があります。
そのため台帳は「サイト」「ホスト名」「証明書」「TLS終端の設置先」の関係を区別し、管理しやすい粒度で記録することが大切です。対象を単純なドメイン一覧だけにすると、更新漏れだけでなく、同じ証明書を何重にも別々の作業として数える誤りも起きます。
NISTも台帳と所有者の明確化を推奨している
米国NISTのTLS Server Certificate Management（SP 1800-16）は、TLS証明書を一元的に把握し、所有者、設置場所、承認者などのメタデータと結び付ける管理を説明しています。更新や監視だけでなく、責任の所在と運用ルールをまとめる考え方が重要です。
この資料は主に組織的なTLS証明書管理を対象とした実務ガイドです。NISTが本記事の台帳の列名や担当者区分を法律上の義務として定めているわけではありません。以下の表や役割分担は、その考え方を小規模・中規模のWebサイト運用にも使えるよう整理した例です。
最初に「サイト・ホスト名・証明書・設置先」を分ける
一元管理の前に、何を一件として数えるか決める必要があります。サイト名、DNS上のドメイン名、証明書の識別情報、証明書が実際に配信される場所は、それぞれ異なる管理対象です。
サイトは事業や用途を表す単位
「コーポレートサイト」「会員サイト」「採用サイト」「オンラインショップ」などがサイトの単位です。担当部署や事業上の重要度を整理するときに使います。一つのサイトが複数のホスト名を使う場合もあります。
サイト管理に必要な項目は、運営部署、サービス名、重要度、外部委託先などです。サイト名が同じでも、HTTPS接続の技術的な対象は別なので、次のホスト名と紐付けて管理します。
ホスト名はHTTPS接続を確認する単位
example.com、www.example.com、app.example.com は別のホスト名です。複数のホストが同じ証明書を使用する場合でも、CDNやロードバランサーの構成によって、実際に提示される証明書が異なる可能性があります。
期限確認や更新後の接続確認を行う対象として、公開URLとホスト名を記録します。DNSで転送しているURL、サブドメイン、顧客向けAPIなど、サービス利用で重要な接続先を見落とさないようにします。
証明書は識別情報と対象名で管理する単位
証明書には有効期間、発行者、シリアル番号、SANに記載された対象名などの情報があります。一つの証明書で複数のホスト名をカバーする場合があるため、証明書を区別するための管理IDや識別情報と、使用するホスト名との関係を残します。
証明書を更新すると新しい証明書が発行されるため、シリアル番号などの識別情報が変わる場合があります。台帳の内部管理IDは継続しつつ、新旧の証明書の識別情報と更新履歴を残すと追跡しやすくなります。
設置先はWebサーバー・CDNなどのTLS終端を表す
HTTPS通信を受け付け、証明書を提示する場所をTLS終端と呼びます。Nginx・Apacheなどのサーバー、ロードバランサー、CDN、マネージドサービスがその例です。ひとつの公開ホスト名について、CDNとオリジンサーバーで別々の証明書を管理する構成もあります。
どこに証明書を設定するのかが分からなければ、更新担当者を決めても変更作業を完了できません。証明書ファイルを管理する場所と、利用者が実際に接続する公開側の場所を区別しましょう。
SSL証明書管理台帳に必要な項目
台帳は複雑に作ることが目的ではありません。更新漏れを防ぎ、担当者が変わっても対処できる最低限の情報を、ひとつの記録へ集めることが目的です。サイト数が少ない場合は表計算でも始められます。
最初に登録する基本項目
次の表では、公開URL、証明書、責任者、確認状況を管理するための項目を整理しました。すべてを一枚の表で表現しにくい場合は「サイト一覧」「証明書一覧」「更新履歴」の3シートに分けて、共通の管理IDで紐付ける方法もあります。
| 管理項目 | 内容・記入する理由 | 例 |
|---|---|---|
| サイト・用途 | 何の業務に使用するか | 会員サイト／ログイン |
| 対象URL・ホスト名 | 実際にHTTPS接続を確認する場所 | https://app.example.com |
| 証明書管理ID | 複数ホストと同じ証明書を紐付ける番号 | CERT-002 |
| 発行元・種類 | 利用している認証局・発行方式 | Let’s Encrypt／DV |
| 証明書の有効期限 | 終了日時とタイムゾーン | 2027/01/20 09:00 JST（架空） |
| 公開先・TLS終端 | 更新・反映すべき構成 | CDN／Nginxなど |
| 更新方式 | 自動・手動と管理するサービス | ACME自動更新 |
| 更新責任者 | 更新が完了するまで説明責任を持つ人 | 情報システム担当 |
| 作業担当・委託先 | 設定変更や更新作業を実施する人 | 保守会社A |
| 代行者・承認者 | 不在時の対応、変更承認 | 運用リーダー |
| 最終確認日時・結果 | 記録が新しいか、失敗していないか | 2026/10/26・成功（架空） |
| 更新状況・次回対応 | 未着手・作業中・反映確認済みなど | 通常／次回確認予定 |
証明書のシリアル番号、SAN、アプリの識別子、管理画面の場所、保守契約の窓口なども必要に応じて追加できます。ただし、管理台帳に秘密鍵そのもの、パスワード、APIトークンを貼り付けないでください。認証情報は適切な秘密情報管理の仕組みで保護し、台帳には安全な管理場所や問い合わせ先だけを記録します。
期限だけでなく確認日時を記録する
証明書の期限が一覧に表示されていても、その値が半年前の確認結果であれば、現在の状況とは一致しない可能性があります。「いつ・どの経路で確認したか」を期限とセットで記録し、最新の情報を把握できるようにします。
監視サービスから自動取得する場合も、取得失敗や直近の成功日時を区別しましょう。期限の日付だけを転記した台帳では、監視が停止していることを見逃す恐れがあります。
ドメインの契約期限とSSL証明書の期限は別に管理する
ドメイン名の契約更新期限と、TLSサーバー証明書の有効期限は別のものです。ドメイン契約が有効でも証明書が期限切れになる場合がありますし、証明書が有効でもドメイン契約やDNSに問題があればWebサイトへ接続できなくなる可能性があります。
ドメイン契約の台帳とSSL証明書の台帳を共通のサイト管理IDで紐付ける方法はありますが、両者を一つの「期限」という欄で上書きしないようにします。
複数サイトの証明書管理台帳の記入例
実際にどのように記録するか、三つのWebサイトを管理するケースで整理します。ここに登場するサイト・担当者・期限はすべて説明用の架空例であり、実在するサービスの監視結果ではありません。
会社サイト・会員サイト・ECサイトを分けた例
会社サイトは共用証明書、会員サイトは自社サーバー、ECサイトは外部管理サービスという構成を考えます。このように発行元や担当者が異なる場合、一括管理の画面があっても、実際に更新する人まで同一とは限りません。
| サイトと公開URL（架空例） | 証明書ID | 期限（JST・架空） | 更新方式／担当 | 確認担当 |
|---|---|---|---|---|
会社サイトhttps://example.com |
CERT-001 | 2027/01/20 09:00 | 共用サーバーの自動SSL／制作会社A | 広報担当 |
会社サイトhttps://www.example.com |
CERT-001 | 2027/01/20 09:00 | 同上（同じ証明書の想定） | 広報担当 |
会員サイトhttps://app.example.com |
CERT-002 | 2027/02/12 09:00 | VPS／Certbot・技術担当B | 運用担当C |
ECサイトhttps://shop.example.net |
CERT-003 | 2027/01/08 09:00 | EC基盤の管理機能／外部事業者D | EC運営担当E |
この例の CERT-001 は二つのホスト名で使用する想定なので、公開URLを二行で管理しても、証明書の実体は一つです。一方、会員サイトとECサイトは別の更新方式なので、それぞれ異なる担当者と確認先を記録します。実際の台帳では、利用している証明書のSANや配信構成を確認して関係を特定してください。
同じ証明書を使う複数URLは紐付けを残す
共通の証明書を二つのホスト名で使う場合、更新作業を二重に依頼する必要がないことがあります。しかし、片方だけ別のサーバーに古い証明書が設定されている場合は、利用者から見える結果が異なることもあります。
そのため「証明書管理ID」と「公開URL」は一対一と決めつけず、ひとつの証明書に対する複数の公開先を紐付けます。更新担当者は証明書を更新し、確認担当者は重要な公開URLごとに正しい証明書が提示されることを確認します。
CDNとオリジンを別行にするケース
会員サイトの前にCDNを置いている場合、ブラウザ向けのCDN証明書と、CDNからオリジンサーバーへ接続する際の証明書が別になることがあります。この場合は、同じホスト名のサービスでも「CDN側の証明書」と「オリジン側の証明書」を別の管理対象として登録します。
公開側の期限だけを見て「すべて正常」としないよう、どの接続区間の証明書を確認したかを記録してください。内部の証明書について外部からの監視では把握できない構成もあります。
更新責任者・作業担当者・代行者の役割を決める
期限が分かっていても、更新する権限を持つ人と、作業を完了と判断する人が不明確だと、対応漏れが起こり得ます。複数サイト管理では、責任の所在を一人に集中させず、必要な役割を分担します。
最低限決めたい4つの役割
「更新責任者」は期限切れが起きないよう対応を管理する人、「更新作業者」は実際に証明書を発行・適用する人、「確認担当者」は公開URLでの結果を確認する人、「代行・エスカレーション先」は主担当が不在・未対応の場合に引き継ぐ人です。これらを兼任しても構いませんが、役割がなくなることとは異なります。
| 役割 | 主な担当内容 | 記入・引き継ぎ例 |
|---|---|---|
| 更新責任者 | 期限管理、作業手配、完了確認 | 情報システム責任者 |
| 更新作業者 | 証明書発行、サーバー・CDNへの反映 | 保守会社Aの担当者 |
| 確認担当者 | 公開HTTPSと主要画面の動作確認 | サービス運用担当 |
| 代行者・連絡先 | 不在時の引き継ぎ、未解決時の連絡 | 運用リーダー／別の保守窓口 |
たとえば作業者が「証明書の更新に成功した」と報告しても、確認担当者が公開接続の結果をまだ見ていなければ、更新作業の報告とサービス側の確認を区別します。「誰が見たら完了か」を先に決めることで曖昧さを減らせます。
担当者ごとの対応例：期限が近いサイトを見つけた場合
会員サイトの証明書に対応が必要と分かった場合、運用担当者は台帳の対象URL・期限・更新責任者を確認します。更新責任者は作業者へ対象を伝え、作業者が実施内容と結果を記録します。その後、確認担当者が正式なURLでHTTPSの正常性を確認し、責任者が台帳の状態を「完了」へ変更する、という流れが考えられます。
期限までの余裕が短い場合には、誰が代行するのか、外部保守会社の対応時間外なら誰に連絡するのかも決めておきます。通知日数を設計する話とは異なり、ここでは通知を受けた後の責任分担を明確にすることが目的です。
制作会社・外部保守会社には作業範囲を明示する
「サイト保守を依頼しているからSSLも管理されているはず」と推測せず、契約や対応範囲を確認します。証明書の取得、DNSの変更、Webサーバーへの反映、CDNの管理、公開URLでの確認が、それぞれ委託範囲に含まれているか整理しましょう。
外部事業者が一部の更新作業を担っても、自社のサービスとして利用者へ影響が出る場合があります。事業側で確認する窓口をなくさず、連絡先と手順を台帳に紐付けることが重要です。
担当者不在・退職時にも使える連絡先にする
個人のメールアドレスだけを連絡先にすると、異動や退職によって通知や問い合わせが届かなくなることがあります。会社として管理する窓口やチケット管理など、引き継ぎ可能な手段を検討します。
一方、連絡先をグループ化しただけでは、誰が作業を引き受けたか分からなくなることもあります。担当部署・主担当・代行者・確認期限を合わせて記録し、未対応の状態が放置されないようにします。
新規サイトを追加するときの証明書管理フロー
一元管理では、最初に台帳を作って終わりではありません。新しいドメインやサブドメイン、サイトの移転が発生したときに、管理対象を追加・変更する手順が必要です。
手順1：公開するURLとサイトの用途を登録
新規サイトを公開する前に、正式なHTTPSのURL、wwwの有無、サブドメイン、サービス担当部署、運営責任者を記録します。リダイレクト元のURLも必要に応じて別に記録します。
同じサイトへ見える複数のURLでも、TLS接続が別のホスト名で行われる場合があります。公開予定の重要なホスト名を一覧にして、確認範囲を決めます。
手順2：証明書を発行・管理するサービスを確認
レンタルサーバーの無料SSL、クラウドの証明書管理、CertbotなどのACMEクライアント、CDNの証明書機能など、現在利用する方式を記録します。すでに発行済みの証明書でカバーするなら、SANの対象名や管理先との関係を確認します。
新しい証明書を発行する作業自体は管理者が環境に合った手順で行う必要があります。発行・更新方式の詳しい説明はACMEと自動更新の記事をご参照ください。
手順3：設置先・更新責任者・代行者を登録
証明書を使う場所がサーバーなのか、CDNなのか、ロードバランサーなのかを確認し、更新責任者と実際の作業者を記録します。複数の会社が関わる場合は、変更を依頼する窓口を明確にします。
作業者が不在の場合に代行する人や、委託先の連絡が取れない場合のエスカレーション先も登録すると、運用開始後の混乱を減らせます。
手順4：公開後の証明書とHTTPS接続を確認
管理画面に証明書が登録されていても、実際の公開URLで適切に提示されていることを確認します。証明書の有効期間、対象ホスト名、HTTPS警告の有無、必要な画面へのアクセスを点検し、確認した日時を台帳へ残します。
同じ証明書を複数ホストで利用する場合でも、公開URLごとに配信先が異なる可能性があります。重要なURLはそれぞれ確認します。
手順5：台帳と監視対象に追加して引き継ぐ
台帳の登録だけでなく、利用している監視・運用ツールで対象を把握できるようにします。SSLの期限確認、監視履歴、担当者への連絡手順を分けて整理し、誰が新しいサイトの保守を受け持つのかを共有します。
サイト公開後に台帳へ登録することを忘れやすいため、公開チェックリストの中に「SSL証明書管理ID・更新責任者の登録完了」という項目を入れると管理しやすくなります。
更新から完了までを管理する担当者別の対応例
実際の更新運用は、通知が表示された時点では終わりません。期限の確認、作業依頼、更新、公開URLでの確認、台帳の更新という一連の流れを、担当者ごとに分けて管理します。
未着手・対応中・確認待ち・完了の状態を分ける
管理台帳の状態として「通常」「要確認」「更新作業中」「公開側の確認待ち」「完了」「確認不能」などの区分を設けると、作業の進み具合を把握しやすくなります。これらは本記事の運用設計例であり、すべての監視サービスに備わる標準ステータスではありません。
特に「更新作業が成功した」と「公開サーバーへ正しく反映された」を一つの状態にしないことが重要です。期限が新しくなっていても別のサブドメインやCDNに古い証明書が残る場合があります。
作業依頼は対象・期日・完了条件をセットで伝える
保守会社やサーバー担当者へ連絡する際は、対象URL、証明書管理ID、現在の期限、配信先、必要な更新内容、希望する確認期限を示します。単に「SSLを更新してください」とだけ伝えると、どのホストや環境が対象か不明確になることがあります。
台帳の作業番号やチケット番号と更新履歴を紐付けると、あとから誰がどの変更を実行したか追えます。顧客情報や秘密鍵を作業依頼に添付する必要はありません。
更新後は作業者と確認担当者で別々に結果を残す
更新作業者は証明書の取得・適用結果を記録し、確認担当者は公開URLでの接続結果と確認日時を記録します。問題が残っていれば「確認待ち」から戻して、追加の確認対象を明確にします。
最終的に責任者が「確認済み」と判断したら、台帳の現在の期限と状態を更新します。次回に同じ問題が起きたときのために、実際の接続先と変更内容を履歴として残しましょう。
「監視結果の取得失敗」は独立した状態にする
HTTPS接続やネットワークの問題で証明書を確認できなかった場合は、以前に保存した有効期限だけを見て「正常」と断定しません。最後に取得できた日時と、現在は確認不能であることを区別します。
取得失敗の原因は期限切れとは限らないため、DNSやTLS接続、サーバーの状態を別に確認する必要があります。監視・通知の詳しい設計は期限監視の記事に分けています。
異動・移転・契約変更のときに台帳を更新する
証明書の台帳は、新しい期限を書き加えるだけでは最新の状態を維持できません。担当者の異動、制作会社の変更、サーバー移転、DNSの変更など、証明書を管理する体制が変わるときに更新することが重要です。
担当者が異動・退職するときの引き継ぎ
引き継ぎでは「管理しているサイトの一覧」「証明書の管理先」「次の更新時期」「未解決の問題」「権限のある作業者」「外部連絡先」を確認します。旧担当者だけが知るパスワードや秘密鍵の保存先がある状態を放置しないよう、認証情報の管理も別途点検します。
引き継ぎ先が台帳を確認し、実際に管理画面へ適切な権限でアクセスできること、必要な情報を取得できることまで確かめます。退職者の権限の取り扱いは、組織のセキュリティルールに従って見直します。
サイトを移転したときの証明書の再確認
レンタルサーバーからVPSへ移転した場合、証明書の発行・更新方式が変わることがあります。同じドメイン名を使い続けても、実際に配信する証明書やTLSの終端先が変わる可能性があります。
移転後は旧サーバー・新サーバー・CDNなどを区別し、管理IDと設置場所、更新担当者、公開側の接続結果を更新します。古い環境が残っている場合は、その管理対象をすぐに削除せず、公開利用の有無を確認して扱いを決めます。
保守会社やDNS管理会社を変更したとき
外部の委託先が変わる場合、証明書の更新作業だけでなく、DNSによるドメイン認証やCDNの設定権限が誰にあるかも確認します。旧委託先へ更新通知が届き続ける運用や、新委託先には権限がない状態を避ける必要があります。
会社が変わった直後に、実際の自動更新を担当するプログラムやアカウントの権限も見直します。証明書の秘密鍵やAPI認証情報は台帳へ記載せず、適切な方法で移管・再設定してください。
台帳を表計算・管理ツール・監視サービスのどれで運用するか
SSL証明書の一元管理に使う道具は、サイト数や担当者数、管理権限、監視機能の必要性によって異なります。「ツールを導入したらすべて解決する」と考えるより、運用する情報を明確にしてから必要な仕組みを選びます。
少数サイトなら共有できる管理台帳から始める
管理するサイトが少ない場合、アクセス権限を設定した表計算や社内の管理表でも、サイト・証明書・更新責任者・履歴の整理を始められます。重要なのは一人だけのPCに保存せず、権限を持つ担当者が参照できるようにすることです。
一方、表計算だけでは公開サイトから最新の証明書を自動的に取得するとは限りません。確認日時や取得失敗を別途管理する必要があります。証明書の期限を確認する仕組みとは役割を分けましょう。
サイト数が増えたら検索・権限・履歴を重視する
数十サイト、数百サイトと増える場合は、担当者別の検索、同じ証明書と複数の設置先の紐付け、変更履歴、未対応の対象の一覧化などが重要になります。利用者ごとの操作権限や承認手順も管理する必要があるかもしれません。
NIST SP 1800-16でも、証明書の発見、台帳、責任者情報、操作権限、継続的な確認を連携させる考え方が示されています。ただし、すべての組織に特定の専用製品の導入が義務付けられるという意味ではありません。
期限監視サービスは台帳を補完する
外部から公開サイトの証明書の有効期限を取得するサービスは、現在の期限を把握するうえで役立ちます。しかし、契約先との連絡や作業の責任分担、秘密鍵の管理、更新後の承認まで、そのサービスが必ず実施するとは限りません。
「証明書の現在の状態を把握する仕組み」と「誰が対応するかを決める運用台帳」を連携させ、両方の役割を明確にすることが大切です。
エンリンクでできることと、別途管理が必要なこと
複数サイトの状況を確認する際には、エンリンクの現行公開機能を利用する方法があります。ただし、このページで紹介した管理台帳のすべての項目をエンリンクが標準搭載しているとは限りません。公開されている機能と、社内で別途運用する情報を分けて説明します。
複数サイトのSSL期限と残り日数を一覧で確認
エンリンクの機能一覧では、登録したWebサイトのHTTPS接続時に確認できたSSL証明書の有効期限と残り日数を表示すると案内しています。管理するサイトが複数ある場合、期限情報をまとめて把握するために利用できます。
また、公開ページではSSL期限接近の管理画面内通知、既読・未読や履歴の管理を案内しています。これは期限を確認するための機能であり、証明書の更新作業や外部保守会社への依頼を自動で代行するという意味ではありません。
更新担当者・代行者・契約先の管理は別途確認
このページの管理台帳に示した更新責任者・代行者・承認者・保守契約先などの詳細な管理が、エンリンクの標準機能としてすべて提供されているとは、現行の公開機能一覧からは確認できません。必要な情報は組織の管理表や契約管理などで補完することを想定してください。
同じく、SSL証明書を認証局へ申請・再発行し、サーバーへ自動適用する機能が提供されているとは案内していません。期限の一元把握と、証明書の発行・更新・管理責任は別の運用です。
無料プランは最大5サイト、定期監視は1日2回
2026年10月26日に確認した料金ページでは、無料プランは最大5サイトの登録と、1日2回の定期監視が案内されています。監視結果の最新性や検知時刻が保証されるわけではありません。
複数サイトのSSL証明書の期限をまとめて把握したい場合は、無料登録から利用を開始できます。サイト数と利用目的に応じてプランを確認してください。
複数サイトのSSL証明書管理でよくある失敗
一元管理を始めても、台帳の更新方法や担当者の確認を怠ると、時間とともに情報が古くなることがあります。見落としやすい失敗を整理し、現場の手順に反映します。
ドメイン名だけ記録して設置先が分からない
台帳にURLと期限だけあっても、更新すべきWebサーバーやCDNが分からなければ作業が進みません。TLS終端の場所と更新方式、管理者への問い合わせ先をセットで記録します。
担当者の連絡先だけで責任が明確になっていない
更新通知を受け取るアドレスがあっても、誰が更新を実施し、誰が最終確認するか不明だと対応漏れが起きる可能性があります。更新責任者・作業者・確認担当者・代行者を整理します。
同じ証明書を複数行に重複登録してしまう
一つのSAN証明書を複数のホスト名で使う場合、URLごとに別の証明書があるように記録すると管理が煩雑になります。証明書管理IDを共通にしつつ、公開URLごとの接続確認は残しましょう。
自動更新成功の報告だけで完了にする
証明書を新しくできても、Webサーバーへの適用やCDNの更新が未完了の場合があります。更新作業者の報告と、利用者側のHTTPS接続確認を分けて記録してください。
期限が近い証明書だけを台帳へ入れる
期限が迫ってから管理を始めると、普段は使用していないサブドメインや、委託先が管理する証明書を見落とす場合があります。新しいサイトの公開やサーバー移転をきっかけに、台帳へ登録する仕組みを用意しましょう。
SSL証明書の一元管理についてよくある質問
台帳を作り始めるときに迷いやすい項目を、複数サイトを管理する観点からまとめます。具体的な更新コマンドや期限監視の設定は別記事で扱っています。
Q．管理するサイトが3つでも台帳を作る必要はありますか？
サイト数が少なくても、管理者やサーバーが異なる場合は台帳が役立ちます。最初はホスト名、証明書の期限、更新方式、主担当、代行者、最終確認日時などから始められます。専用の大規模管理システムを必ず導入する必要はありません。
Q．wwwありとなしは同じ行にまとめてもよいですか？
同じ証明書を使用する場合は管理IDを共通にできますが、HTTPS接続先としては異なるホスト名です。別のサーバーやCDNから異なる証明書が提示されることもあるため、重要な公開URLは個別に確認できるようにしておくと安心です。
Q．無料のSSL証明書でも一元管理は必要ですか？
無料か有料かだけで管理の必要性は決まりません。証明書には有効期間があり、更新の失敗や反映漏れが起きる可能性があります。無料のLet’s Encryptでも、更新方式と担当者の整理は重要です。
Q．更新担当者は制作会社だけにしてよいですか？
委託先が実際の更新作業を担当することはあります。ただし、期限切れで利用者に影響が出る可能性があるため、サービス運営側で更新の状況を確認できる窓口や責任者も明確にしておくことが望まれます。契約で委託範囲を確認してください。
Q．ドメインの契約期限もSSLの台帳に入れますか？
管理全体の視点では関連づける方法がありますが、ドメイン契約の期限とSSL証明書の有効期限は別項目です。同じ欄にまとめず、それぞれの期限と更新責任者を分けて管理してください。
Q．証明書の有効期限が分かれば管理は十分ですか？
期限の把握は重要な第一歩ですが、更新方式・設置先・担当者・確認日時が分からないと、期限が近づいたときに作業を進めにくくなります。一元管理では「誰が何をするか」まで記録することが重要です。
Q．CDNの証明書とサーバーの証明書は別に扱いますか？
CDNがHTTPSを終端し、さらにオリジンとの間もTLSで通信する構成では、異なる証明書を利用することがあります。その場合は接続区間・管理サービス・更新担当者を区別して登録します。
Q．エンリンクだけで更新担当者の管理まで完結しますか？
現行の公式機能一覧で確認できるのは、サイト管理、SSLの有効期限・残り日数表示、管理画面内の期限接近通知などです。更新担当者・承認者・代行者を含むすべての台帳項目が標準機能で管理できるとは確認できないため、必要に応じて別の管理表を利用してください。
まとめ：期限・設置先・担当者を一緒に管理する
複数サイトのSSL証明書を一元管理するには、「対象の公開URL」「証明書の識別情報と有効期限」「証明書を設置する場所」「更新責任者と代行者」「更新後の確認結果」を結び付けることが重要です。まずはサイト・ホスト名・証明書・設置先の違いを整理し、証明書管理IDで関係を追える台帳を作成しましょう。
管理台帳ができたら、サイト公開時の登録、更新作業の依頼、反映確認、担当者変更時の引き継ぎまでを同じ運用に含めます。期限を知らせるだけでなく、通知後に誰が動き、どの時点で完了になるかを決めておけば、複数人・複数社が関わる環境でも確認漏れを減らせます。
エンリンクの機能一覧では、登録サイトのSSL証明書の有効期限・残り日数、期限接近の管理画面内通知を案内しています。複数サイトの期限情報をまとめて確認したい場合は料金プランを確認のうえ、無料アカウント登録をご利用いただけます。更新担当者や保守会社の管理は別途整理する運用として扱います。
参考資料・確認日
記事の基礎となる一元管理・責任分担・期限制度について、次の一次資料を参照しました（確認日：2026年10月26日）。管理表の列名や架空の役割分担は本文独自の実務例であり、法律上の義務やエンリンクの標準画面を示すものではありません。
- NIST SP 1800-16：Securing Web Transactions — TLS Server Certificate Management — 所有者の明確化、証明書の一元管理、更新・監視・確認の基本。
- NIST SP 1800-16B：管理プログラム・インベントリ — 追加メタデータ、設置先、管理者情報、役割と責任の整理。
- CA/Browser Forum：TLS Baseline Requirements — 公開TLS証明書の有効期間・発行要件。
- Certbot公式ユーザーガイド — 証明書の更新・保存と管理方法の参考。
