>
>
公開日
最終更新日
SSLとは何かを簡単に表すと、ブラウザとWebサーバーの間で送受信する情報を暗号化する仕組みです。一般にはSSLと呼ばれていますが、現在の実装は後継規格のTLSが中心です。暗号化によって情報セキュリティにおける機密性と完全性を支え、パスワードや決済情報などの認証情報を通信経路上の盗聴から守ります。
本記事は、SSLの意味を知りたい初学者だけでなく、証明書を実際に設定するWeb担当者や情シス担当者も対象としています。TLS 1.3の仕組み、DV・OV・EVの違い、常時SSL化、ACMEによる更新自動化、証明書チェーンやドメイン不一致などのSSLエラーまで、運用判断に使える形で整理します。
SSLとは？TLS・HTTPSとの違いと仕組み
SSLとは通信を暗号化する技術の通称であり、現在はSSLそのものではなくTLS 1.2またはTLS 1.3が利用されています。
読者別の読み方
初心者向け：「Secure Sockets Layerの意味」「SSL・TLS・HTTPSの違い」から読むと、SSLの基本用語を整理できます。
設定担当者向け：「SSLの設定・移行手順と確認項目」「SSLエラーの原因と失敗パターン」で、移行と障害対応の手順を確認できます。
大規模運用向け：「2026年以降の証明書有効期間短縮と自動化」「国内企業の証明書運用事例と規模別の体制」で、証明書管理の自動化と体制設計を確認できます。
ポイント | 内容 |
|---|---|
SSL/TLSの実体 | 「SSL通信」と呼ばれる通信は、主にTLS 1.2またはTLS 1.3が動いています |
SSL/TLSの役割 | 通信の暗号化・改ざん検知・接続先サーバーの認証を担います |
HTTPSとの関係 | HTTPSはHTTPをSSL/TLSで保護したWeb通信で、URLがhttps://で始まります |
有効期間短縮の対象 | 2026年以降の段階的短縮は公開Web PKI発行のTLSサーバー証明書が対象です。社内CAや非公開用途への一律適用ではありません |
Secure Sockets Layerの意味
Secure Sockets Layerは、直訳すると「安全なソケット層」を意味します。Netscapeが開発したSSLはSSL 3.0まで存在しましたが、既知の脆弱性があるため現行システムでは使用しません。現在は後継のTransport Layer Security、略してTLSが通信を保護しています。
サイトや製品の説明では「SSL証明書」「SSL化」という名称が定着しているため、本記事でも一般的な呼び方としてSSLを使います。ただし、サーバー設定を調査するときは、TLSのバージョンと暗号スイートを調べるのが正確です。
SSL/TLSが担う通信保護
SSL/TLSには、通信内容を第三者から読みにくくする機密性、途中で書き換えられていないことを検証する完全性、接続先が証明書の対象ドメインであることを検証するサーバー認証という役割があります。ログイン情報、Cookie、問い合わせ内容、APIのデータなどが主な保護対象です。
一方、SSL/TLSはWebアプリケーション内部のSQLインジェクションやクロスサイトスクリプティング、管理画面への不正ログインを防ぎません。HTTPS化済みでも、脆弱性診断、アクセス制御、多要素認証、WAF、ログ監視は別に設計します。
TLSハンドシェイクと暗号化通信
TLS通信は、ブラウザとサーバーが利用可能な暗号方式を提示するところから始まります。サーバーは証明書と中間CA証明書を返し、ブラウザは有効期限、対象ドメイン、認証局までの証明書チェーン、失効状態などを検証します。
通信条件の合意：クライアントとサーバーがTLSバージョンや暗号方式を決めます。
証明書の検証：ブラウザが証明書の署名、ドメイン名、有効期限、認証局への信頼経路を検証します。
通信鍵の導出：ECDHEなどの鍵交換を使い、双方が同じ通信鍵を導出します。サーバーは秘密鍵を送信せず、対応する秘密鍵を保有していることを署名で証明します。
共通鍵暗号への移行：確立後の大量データは、処理の速いAES-GCMやChaCha20-Poly1305などの共通鍵暗号で保護します。
TLS 1.3は、TLS 1.2よりハンドシェイクの往復回数を減らし、古い暗号方式を仕様から除外しています。ただし、0-RTT通信には再送攻撃のリスクがあるため、決済や状態変更を伴う処理で無条件に使う構成は避けます。
SSL・TLS・HTTPSの違い
SSLとTLSは通信を保護するプロトコルであり、HTTPSはその保護をHTTPに適用したWeb通信です。
用語 | 意味 | 現在の扱い |
|---|---|---|
SSL | 暗号化通信プロトコルの旧規格、またはSSL/TLSの通称 | SSL 2.0・3.0は使用せず、名称だけが広く残っています |
TLS | SSLの後継となる暗号化通信プロトコル | TLS 1.2とTLS 1.3が中心です |
HTTPS | HTTPをTLSで保護したWeb通信 | URLがhttps://で始まります |
Google Chrome 117以降では、従来の鍵マークに代わってサイト設定を示すアイコンが表示されます。HTTPS表示は通信が暗号化されている目安ですが、サイト運営者の善意や商品の安全性までは保証しません。フィッシングサイトも正規のDV証明書を取得できるため、ドメイン名や運営者情報を別途見分けます。
▲ HTTPSにおけるHTTPとSSL/TLSのレイヤー構成と保護の仕組み
SSLサーバ証明書の種類と選定基準
SSLサーバ証明書は暗号強度だけでなく、認証範囲、対象ドメイン、サポート、更新方法を同じ軸で比較して選びます。
DV・OV・EVの認証レベル
DV、OV、EVは、認証局が申請者をどこまで確認するかを表す区分です。同じTLSバージョンと暗号方式を使う限り、DVよりEVの暗号が強いわけではありません。違いは、ドメインの管理権限だけを確認するか、組織の法的実在性まで審査するかにあります。
認証レベル | 認証内容 | 組織情報 | 主な対象 | 発行・運用上の注意 |
|---|---|---|---|---|
DV | ドメインの管理権限 | 証明しません | 一般サイト、ブログ、検証環境、API | 短時間で発行しやすく、ACMEとの相性が良好です |
OV | ドメインと組織の実在性 | 証明書情報に含まれます | 企業サイト、法人向けサービス | 組織審査と更新手続きの所要時間を運用計画に含めます |
EV | OVより詳細な組織審査 | 厳格な基準で確認します | 金融、公共、大規模取引サイト | 現在の主要ブラウザは企業名を常時強調表示しません |
取引先のセキュリティ基準や監査で組織認証が指定されていればOVまたはEVを選び、指定がなく暗号化と自動更新を優先する公開サイトならDVが候補です。OVやEVを使ってもフィッシングを自動的に遮断するわけではないため、ドメイン監視やメール認証と組み合わせます。
無料SSLと有料証明書の違い
無料証明書と有料証明書の暗号強度は、同じ鍵長とTLS設定なら基本的に変わりません。無料の代表例であるLet's EncryptはDV証明書を発行し、ACMEを使った自動更新を前提にしています。Let's Encryptの公式FAQでは、証明書の有効期間を90日と案内しています。
有料証明書では、OV・EVの組織審査、発行時の有人サポート、契約上の保証、管理画面やAPI、監査向け書類などが選定軸になります。料金と保証条件は契約形態で変わるため、DigiCertの公式情報やセコムトラストシステムズの公式情報で、発行方式、再発行条件、ACME対応、サポート時間を同じ表に転記すると比較できます。
単一・マルチドメイン・ワイルドカードの範囲
単一ドメイン証明書は対象を限定できるため、秘密鍵が漏えいした場合の影響範囲を抑えやすい方式です。マルチドメイン証明書はSAN領域に複数の異なる名前を登録でき、example.comとexample.jpのような組み合わせにも対応します。ただし、証明書を共有した全ドメインが証明書情報から見える点に注意します。
ワイルドカード証明書の*.example.comは、原則としてwww.example.comやapi.example.comなど1階層下を対象にします。example.com自体やdev.api.example.comのような多階層名は自動的には対象になりません。ルートドメインも保護するならSANへ別名として追加します。
複数サーバーへ同じワイルドカード秘密鍵を配布すると、一台の侵害が全サブドメインへ波及します。DNS APIを安全に利用できる環境では、ACMEでサービス単位の証明書を発行し、秘密鍵の共有範囲を小さくする構成が管理しやすくなります。
▲ 自社サイトに適したSSL証明書（DV / OV / EV）の選定フロー
常時SSL化が必要な理由と安全性の限界
公開Webサイトでは全ページをHTTPSにする常時SSL化が標準ですが、HTTPSだけでサイト全体の安全性が完成するわけではありません。
常時SSL化の国内普及状況
部分SSLでは、ログイン後だけを暗号化しても、HTTPで配信したページやCookieが攻撃の入口になり得ます。そのため、トップページ、画像、CSS、問い合わせ、ログイン、APIを含む全通信をHTTPSへ統一します。
株式会社フィードテイラーは、2026年3月時点の国内上場企業サイト調査で常時SSL化率94.2％と公表しています。調査対象やリダイレクトの判定条件によって数値は変わるため、この値は株式会社フィードテイラーが公表する調査の対象範囲における結果として扱います。国内主要企業を対象にした近年の調査は、おおむね90％台の普及を示しており、HTTPのみの企業サイトは少数です。
SEO・通信性能・利用者保護への効果
GoogleはHTTPSを検索順位のシグナルの一つとして扱っていますが、HTTPSへ変更しただけで順位が大幅に上がるとは限りません。検索評価より先に、ブラウザ警告の回避、入力情報の暗号化、参照元情報の適切な受け渡しといった利用者保護を目的にします。
HTTP/2やHTTP/3は、複数リクエストの効率化や接続遅延の削減に寄与します。HTTP Working GroupのRFC 9113はHTTP/2の多重化などを定義しています。ただし、表示速度はサーバー実装、CDN、画像容量、JavaScript、回線品質にも左右され、HTTPSだけで高速化するわけではありません。
HTTPSで防げない攻撃
HTTPSはブラウザと接続先の間を保護しますが、接続先自体が攻撃者のサイトなら、入力内容は暗号化されたまま攻撃者へ届きます。また、サーバーへ侵入された後の情報流出、脆弱なWebアプリケーション、マルウェア、権限設定ミスも別の問題です。
フィッシング対策には、類似ドメイン監視、DMARC、利用者への周知を組み合わせます。
Webアプリケーション攻撃には、更新管理、脆弱性診断、WAF、セキュアコーディングを組み合わせます。
アカウント侵害には、多要素認証、最小権限、異常ログイン検知を組み合わせます。
秘密鍵の漏えいには、アクセス制限、鍵の非エクスポート化、失効・再発行手順を組み合わせます。
SSLの設定・移行手順と確認項目
SSL設定は、証明書をインストールするだけでなく、HTTPからの転送、混在コンテンツ、TLS設定、監視までを一つの変更計画として扱います。
移行前の証明書インベントリ
最初に、公開サイトだけでなくAPI、ロードバランサー、CDN、メールゲートウェイ、VPN、Kubernetes、社内システムを含めて証明書を棚卸しします。管理表にはFQDN、証明書の発行元、有効期限、秘密鍵の保管先、更新担当、更新方式、利用システムを記録します。
同じドメインでもCDNのエッジ、ロードバランサー、オリジンサーバーに別の証明書が存在する場合があります。外部から見える証明書だけを調べるとオリジン側の期限切れを見逃すため、終端ごとに一行を割り当てます。
Webサーバーと証明書チェーンの設定
Webサーバーにはサーバー証明書、対応する秘密鍵、認証局が指定する中間CA証明書を設定します。秘密鍵と証明書の公開鍵が一致しない場合は起動や再読み込みに失敗するため、変更前に組み合わせを検証します。
NginxやApacheでは、証明書ファイルを置き換えただけでは稼働プロセスへ反映されない構成があります。設定テストに成功した後でreloadし、外部から提示されるシリアル番号と有効期限が新しい値へ変わったことまで確認します。失敗時に旧ファイルへ戻せるよう、直前の証明書と設定を保管します。
HTTPリダイレクトと混在コンテンツの解消
HTTPSで正常に表示できる状態を作ってから、HTTPへのアクセスを同一URLのHTTPSへ301リダイレクトします。すべてをトップページへ転送すると検索インデックスや利用者のブックマークに影響するため、パスとクエリ文字列を維持します。
HTMLがHTTPSでも、画像、CSS、JavaScript、iframe、APIをHTTPで読み込むと混在コンテンツになります。ブラウザが一部のリソースを遮断すると、画面崩れや決済機能の停止が起きます。ブラウザの開発者ツールでブロックされたURLを抽出し、自社URLはHTTPSへ変更し、HTTPS非対応の外部部品は置き換えます。
HSTSの段階的な適用
HTTP Strict Transport Securityを有効にすると、対応ブラウザは指定期間中、そのドメインへHTTPSでのみ接続します。通信のダウングレード防止に役立つ一方、証明書障害時もHTTPへ戻せなくなります。
最初は短いmax-ageで対象ドメインだけを検証し、更新と障害復旧を確認できた段階で期間を延ばします。includeSubDomainsは全サブドメインのHTTPS対応が確認できれば有効化し、HTTPしか使えないサブドメインが残るなら先に移行します。preload登録は取り消しの反映に時間がかかるため、全サブドメインの運用責任が一元化されてから判断します。
公開前後の確認チェックリスト
以下の項目を変更記録へ貼り付けると、設定者と確認者の役割を分けられます。
対象FQDNが証明書のSANに含まれている
サーバー証明書と秘密鍵が一致している
中間CA証明書を含む完全なチェーンを返している
TLS 1.2またはTLS 1.3で接続できる
HTTPからHTTPSへ同じパスで転送される
画像、CSS、JavaScript、APIに混在コンテンツがない
更新後にWebサーバーまたはロードバランサーへ反映される
外形監視が期限、応答、証明書チェーンを検査している
API、モバイルアプリ、旧端末からの接続試験が完了している
失敗時に旧設定へ戻す担当者と手順が決まっている
▲ SSL/TLS証明書の設定および移行を進める4段階の手順
2026年以降の証明書有効期間短縮と自動化
証明書更新の自動化は法令上の一律義務ではありませんが、公開TLSサーバー証明書が2029年に最長47日となる前提では、手作業だけでの更新運用は障害リスクを高めます。ここで扱う短縮スケジュールは、公開Web PKIで発行されるTLSサーバー証明書が対象です。社内CA、非公開の業務システム、利用製品の独自ルールには同じ期限が適用されない場合があるため、対象・提供状況は各認証局の証明書プロファイルと利用中のプラットフォームの管理画面で確認します。公開TLSサーバー証明書であることを確認できれば本節の更新周期で台帳と自動化を設計し、確認できなければ当該CAの証明書ポリシーに記載された期限を基準に管理します。
CA/Browser Forumの短縮スケジュール
CA/Browser Forumは2025年4月、Ballot SC-081v3を採択し、公開TLSサーバー証明書の最大有効期間とドメイン名・IPアドレス検証情報の再利用期間を段階的に短縮するスケジュールを決定しました。CA/Browser ForumのBallot SC-081v3（2025年4月11日付）および同団体のServer Certificate Baseline Requirementsで、発行日を基準に適用される上限を確認できます。NISTのFIPS 203はNIST CSRC（csrc.nist.gov/pubs/fips/203/final）で全文を参照できます。
発行日 | 証明書の最大有効期間 | 運用への影響 |
|---|---|---|
2026年3月14日まで | 398日 | 従来はおおむね年1回の更新でした |
2026年3月15日以降 | 200日 | 年2回程度の発行・配布が発生します |
2027年3月15日以降 | 100日 | 年4回程度の発行・配布が発生します |
2029年3月15日以降 | 47日 | 単純計算で年8回以上の更新周期になります |
CA/Browser ForumのBallot SC-081v3では、ドメイン名・IPアドレスの管理権限を検証した情報の再利用可能期間も、2026年3月15日以降は200日、2027年3月15日以降は100日、2029年3月15日以降は10日へ短縮されます。証明書ファイルの配布だけを自動化しても、ドメイン検証が人手のメール承認に残っていれば更新が止まるため、検証から配布、反映、監視までを連続した処理にします。
ACMEのHTTP-01とDNS-01
ACMEは、認証局とサーバーの間でドメイン検証、証明書発行、更新を自動化するプロトコルです。公開Webサーバーで80番ポートへ到達できるならHTTP-01が扱いやすく、ワイルドカード証明書や外部非公開サーバーにはDNS-01を使います。
検証方式 | 適する環境 | 制約 | 判断基準 |
|---|---|---|---|
HTTP-01 | インターネットから到達できるWebサーバー | 80番ポートへの到達が前提で、ワイルドカードには使えません | 対象サーバーへ検証ファイルを安全に配置できれば選択します |
DNS-01 | ワイルドカード、内部サーバー、複数拠点 | DNS更新権限の保護が課題です | 権限を対象ゾーンと検証用レコードに限定できれば選択します |
TLS-ALPN-01 | TLS終端を直接制御できるサーバー | ロードバランサーやCDNによって対応差があります | 利用製品が自動応答に対応していれば候補にします |
DNS-01でDNS事業者の全権限APIキーを各サーバーへ置く構成は避けます。検証専用ゾーンへの委任、短期トークン、送信元制限、秘密情報管理サービスを使い、Webサーバーの侵害からDNS全体を切り離します。
CLMとKubernetes環境の運用
証明書ライフサイクル管理、略してCLMは、証明書の発見、申請、承認、発行、配布、更新、失効を一元管理する仕組みです。複数の認証局、クラウド、ロードバランサー、社内PKIをまたぐ企業では、ACMEクライアントだけでなくインベントリと監査ログを持つCLMが適します。
Kubernetesではcert-managerなどを使い、IngressやGatewayへ証明書を自動配布できます。ただし、更新成功というイベントだけでは十分ではありません。Secretが更新された後にIngress Controllerが新証明書を読み込み、外部から新しいシリアル番号が返るところまで監視します。
更新工数の試算
証明書100枚を手作業で管理し、1回の申請・配布・確認に30分かかるモデルでは、47日周期の年8回更新で年間400時間です。自動化後に例外対応が全更新の5％まで下がると仮定すれば、人手対応は40件、年間20時間となり、差は380時間です。実際の削減量は審査、変更承認、対象機器のAPI対応によって変わりますが、枚数を入れ替えるだけで自社の運用負荷を試算できます。
クライアント認証用途の分離
GoogleはChrome Root Program Policy Version 1.8で、Chrome Root Storeに含まれるルート配下の公開TLSサーバー証明書について、2027年3月15日以降に発行されるSubscriber Certificateは、Extended Key Usageにid-kp-serverAuthのみを含める条件を示しています。同ポリシーでは、2026年6月15日は中間CA証明書に関する制限の開始日です。社内用途だけで運用するプライベートCAは、Chrome Root Program Policyの対象外と案内されています。
証明書のExtended Key UsageにserverAuthとclientAuthの両方があり、公開認証局から取得している場合は、2027年3月15日以降の更新前に用途を分離します。EDIやAPIの接続先が独自CAを受け入れられるならプライベート証明書へ移し、受け入れられないなら接続先の証明書要件を確認します。接続先が専用クライアント証明書を受け入れることを確認できれば発行経路を分け、確認できなければ接続方式と更新時期を調整します。
耐量子計算機暗号への備え
NISTは2024年8月、格子暗号を使う鍵カプセル化方式ML-KEMをFIPS 203として確定しました。ブラウザやCDNでは、TLS 1.3の鍵交換を従来方式とML-KEMで組み合わせる移行が進んでいます。
この動きは、公開Web PKIのサーバー証明書が直ちにPQC証明書へ置き換わるという意味ではありません。2025～2026年の情シス部門では、TLS終端装置、WAF、プロキシ、監視製品が大きなClientHelloやハイブリッド鍵交換を正常に扱えるかを検証対象にします。接続失敗が起きるなら機器更新またはファームウェア対応へ進み、問題がなければ現在の公開証明書運用を保ちながら標準化を追跡します。
国内企業の証明書運用事例と規模別の体制
証明書運用は、管理枚数とシステムの分散度に応じて、ホスティング任せ、一元管理、API連携へ段階的に切り替えます。
サイバーエージェントの申請・更新集約
サイバートラストが公開するサイバーエージェントの事例では、iTrust SSL/TLSの運用サービスSureHandsOnを使い、多数のドメインとサーバーに関する証明書の発行・更新手続きを集約しています。なお、API連携を活用した事例としては、同社がニフティ株式会社などを別途紹介しています。個別担当者が認証局の画面へログインする運用から、申請経路と権限を一本化する考え方が参考になります。
公開事例では管理枚数や削減時間の詳細が示されていないため、導入効果を固定値では置きません。自社では、証明書1枚当たりの申請時間、更新失敗件数、期限30日前で未更新の件数を導入前後で測ると、集約の効果を比較できます。
さくらインターネットとセイコーソリューションズの管理基盤
証明書管理基盤を選ぶ際は、可視化、申請、適用のどこまでを対象にするかを分けて整理します。さくらインターネットおよびセイコーソリューションズは、それぞれの製品ページや導入事例ページで証明書管理機能の対応範囲を公開しています。ロードバランサー、仮想サーバー、CDN、複数担当部署をまたぐ場合は、証明書台帳と所有者情報を統合し、各機器へ適用できる範囲を各製品の仕様ページで確認します。対象製品がAPIを提供していれば自動連携の対象になり、未提供であれば手動手順との組み合わせになります。
レガシー機器へ直接API連携できない場合でも、管理基盤から期限と所有者を把握し、対応可能なサーバーから自動化できます。全台の同時移行を前提にせず、期限切れ時の影響が大きい外部公開システムを先に対象とします。
公共・自治体での組織認証の活用
自治体や公共分野では、住民向けサイトや公共システムにおいて、暗号化に加えて証明書発行時の組織確認を選定条件に含めるケースがあります。組織の実在性を審査するOVまたはEV証明書が採用される理由の一つは、監査対応や調達要件で組織認証の取得が条件として示される場合があるためです。
OV・EVは正規組織による申請であることを認証局が確認しますが、ブラウザ画面だけでフィッシングを判別できる仕組みではありません。自治体ドメインの周知、類似ドメイン監視、送信メールのDMARCと併用して判断します。
Cloudflareのエッジ・オリジン分離
CDNを使う構成では、利用者からCDNまでのエッジ証明書と、CDNから自社サーバーまでのオリジン証明書を分けられます。Cloudflareではエッジ側の公開証明書を自動管理し、オリジン側にCloudflare Origin CAなどの証明書を設定する構成があります。
Origin CA証明書はCloudflareとオリジン間の用途であり、一般的なブラウザが直接信頼する証明書ではありません。保守回線やCDN迂回経路からブラウザで直接接続する要件があるなら公開証明書を使い、迂回を禁止できるならファイアウォールでCloudflareの接続元だけを許可します。エッジが正常でもオリジン証明書が失効すると502系エラーになるため、両方を別々に監視します。
企業規模別の運用モデル
従業員数は目安であり、最終的には証明書枚数とTLS終端数で体制を決めます。
組織・環境の目安 | 運用モデル | 判断条件 |
|---|---|---|
50名未満、証明書10枚未満 | マネージドホスティングまたはACME自動更新 | 全証明書を一つの台帳で把握でき、更新失敗アラートの担当者が2名以上いれば運用できます |
50～300名、証明書10～100枚 | 共通ACME基盤と一元台帳 | 部署ごとの所有者、期限監視、変更記録を中央で管理できれば分散サーバーにも対応できます |
300名超、証明書100枚超 | CLM、API連携、秘密情報管理基盤 | 複数認証局やクラウドを横断するなら、発見から失効までの監査ログを一元化します |
SSLエラーの原因と失敗パターン
SSLエラーは、ブラウザのキャッシュを消す前に、期限、ドメイン名、証明書チェーン、端末時刻、TLS設定の順で切り分けます。
エラー表示別の原因と対処
GoogleのChromeヘルプ「安全でないサイトについての警告表示」では、証明書や安全でないページに関する警告の意味を案内しています。管理者は画面の文言だけで判断せず、エラーコードとサーバーが実際に返す証明書を照合します。
主な表示・症状 | 主な原因 | 切り分け | 管理者側の対処 |
|---|---|---|---|
ERR_CERT_DATE_INVALID | 証明書の期限切れ、開始日前、端末時刻のずれ | 証明書のNot Before・Not Afterと端末時刻を比較します | 全端末で起きるなら証明書を更新し、一台だけなら時刻同期を直します |
ERR_CERT_COMMON_NAME_INVALID | アクセス先がSANに含まれない | URLのFQDNとSANを比較します | 正しいFQDNを含む証明書を発行し、SNIとVirtualHostを修正します |
ERR_CERT_AUTHORITY_INVALID | 未信頼CA、中間証明書の不足、社内CAの未配布 | 別端末と証明書チェーンを比較します | 中間CAを設定し、社内CAなら管理対象端末へルート証明書を配布します |
ERR_SSL_PROTOCOL_ERROR | TLSバージョン、暗号方式、プロキシ、待受ポートの不整合 |
| TLS 1.2・1.3と対応暗号を有効にし、TLS終端の設定先を特定します |
ページの一部だけ動かない | 混在コンテンツ、CORS、古いAPI URL | ブラウザのConsoleとNetworkを調べます | HTTPリソースをHTTPSへ変更し、外部部品の対応状況を整理します |
中間CA証明書の適用漏れ
サーバー証明書だけを更新し、中間CA証明書を古いまま残すと証明書チェーンエラーが起きます。管理者のPCでは過去に取得した中間証明書がキャッシュされていて正常に見え、新しい端末やモバイルアプリだけが失敗する場合があります。
更新時は認証局が指定するチェーンをサーバーへ設定し、キャッシュのない外部監視地点から検証します。サーバーがルート証明書まで送る設定も不要なため、サーバー証明書と必要な中間CA証明書で構成します。
更新通知メールへの依存
通知先が退職者の個人アドレスだけになっていると、メールが届いても誰も対応しません。共有メーリングリストだけの場合も、担当と期限が決まらず放置されることがあります。
証明書台帳では主担当と副担当を置き、期限30日前、14日前、7日前のアラートを監視システムから送ります。30日前の時点で更新済み証明書を外部から確認できなければ担当チケットを発行し、7日前に残っていれば管理者へ自動エスカレーションする運用にします。
ワイルドカード証明書の過度な共有
ワイルドカード証明書を多数のサーバーへコピーすると、更新時の配布先が増え、古い証明書の残存と秘密鍵漏えいの影響範囲が大きくなります。開発環境と本番環境で同じ秘密鍵を使う運用は、開発サーバーの侵害を本番へ波及させます。
サービスごとにACMEで発行できるなら証明書を分割します。ワイルドカードが不可欠なら、秘密鍵を非エクスポート型の鍵管理基盤へ置き、利用先をTLS終端装置に限定します。
自動更新後の反映漏れ
ACMEクライアントが更新成功と記録していても、Webサーバーのreload失敗、コンテナへのSecret反映遅延、ロードバランサーの証明書ID更新漏れによって、外部には古い証明書が返る場合があります。
監視対象はローカルファイルの期限ではなく、利用者と同じ経路から取得した証明書の期限とシリアル番号にします。更新処理、設定テスト、reload、外部検証のいずれかが失敗したら完了扱いにせず、旧証明書が有効な間に再実行します。
CDN導入環境の見落とし
CDNのエッジ証明書が正常だと、日常のブラウザ確認ではオリジン証明書の期限切れを発見できません。CDNからオリジンへの厳格な証明書検証が有効な構成では、期限切れの瞬間にオリジン接続が失敗します。
エッジ用FQDNとオリジン用FQDNを監視台帳で分け、オリジン監視はCDN経由と管理ネットワーク経由の両方で行います。オリジンへ直接接続できない構成なら、CDNのヘルスチェック結果とオリジン側の証明書ファイルを監視システムへ送ります。
閲覧者側のキャッシュ削除が有効な範囲
キャッシュ削除で直るのは、古いリダイレクト、HSTS状態、過去の中間証明書、プロキシの応答が端末側に残っている一部のケースです。有効期限切れやドメイン不一致はサーバー側の問題であり、キャッシュを削除しても解消しません。
全端末で同時に起きるならサーバー、CDN、DNSを調べ、一台だけなら端末時刻、OSのルート証明書、セキュリティソフト、社内プロキシを調べます。この分岐によって、利用者へ一律にキャッシュ削除を案内する無駄を減らせます。
よくある質問
SSLの意味、必要性、エラー、自動更新に関する疑問へ簡潔に回答します。
Q：SSLとは簡単にいうと何ですか？
A：SSLとは、ブラウザとサーバーの通信を暗号化し、盗聴や改ざんを防ぐ仕組みの通称です。現在は後継のTLS 1.2またはTLS 1.3が使われています。
Q：SSLはすべてのWebサイトに必要ですか？
A：公開Webサイトでは、入力フォームの有無にかかわらずHTTPS化します。HTTPのままでは通信内容の改ざんやブラウザ警告が発生し、Cookieや閲覧内容も保護できません。
Q：無料SSLと有料SSLで暗号の強さは変わりますか？
A：同じTLSバージョン、鍵長、暗号方式なら、無料か有料かで暗号強度は変わりません。有料証明書はOV・EVの組織審査、有人サポート、保証、管理機能などに違いがあります。
Q：SSLエラーはキャッシュ削除で直りますか？
A：古いリダイレクトや端末側の状態が原因なら直る場合がありますが、有効期限切れ、ドメイン不一致、中間証明書不足は直りません。全端末で起きる場合はサーバー側、一台だけなら端末時刻やルート証明書を調べます。
Q：証明書更新はいつまでに自動化すべきですか？
A：公開TLSサーバー証明書は、2026年3月15日以降は最大200日、2027年3月15日以降は100日、2029年3月15日以降は47日へ短縮されます。公開証明書であることを認証局の証明書プロファイルで確認できれば、直近の更新対象からACMEまたはCLMへ移し、更新後のreloadと外部監視まで自動化します。社内CAなど別のポリシーが適用される場合は、そのCAが定める更新周期に合わせて台帳と監視を設計します。
まとめ
本記事は、クラウド型SaaS管理ツール「Admina」を提供するマネーフォワードi株式会社の編集チームが、情報システム担当者・ウェブサイト運営者向けに作成しました。
SSLとは通信を暗号化する仕組みの通称であり、現在の実体はTLSです。証明書を導入するだけで終わらせず、証明書チェーン、HTTPS転送、混在コンテンツ、更新後の反映、外形監視までを一つの運用として管理します。
最初の一歩は、自社の公開サイト、API、CDN、ロードバランサー、社内システムにある証明書を一枚の台帳へ集めることです。FQDN、有効期限、利用先、担当者、更新方式を記録します。公開TLSサーバー証明書であることを確認できる対象は、2026年の更新対象からACMEによる自動発行と外部監視へ切り替えることで、2029年3月15日以降の最長47日化にも対応できる運用基盤を整えられます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
