Defaults.Exposed › 修正 › TLS証明書の健全性

TLS証明書の健全性 の直し方

あなたのSSL/TLS証明書は、訪問者が本当にあなたのウェブサイトと話していること（偽者ではないこと）を証明するデジタル身分証で、ブラウザの鍵マークを支えています。この検査は、その証明書が有効で信頼され、もうすぐ期限切れにならず、強く最新の暗号で作られているかを見ます。

あなたのビジネスにとっての結論： 証明書が壊れている・期限切れだと、あなたのウェブサイトはどのブラウザでも全画面の赤い『この接続ではプライバシーが保護されません』という警告に置き換わります。ほとんどの訪問者は即座に離れ、戻ってきません。オンライン販売も登録も止まり、本来は守られるはずだった接続が静かに傍受されることもあります。

これで失いかねないもの

• 週末の間に証明書が静かに期限切れになり、月曜には訪問者全員が全画面の警告に当たり、決済も問い合わせフォームも死に、気づいて更新するまでの時間ごとに売上を失います。
• カフェやホテルのWi-Fiで支払う顧客が、証明書がドメインと一致しないという警告を受け取り、サイトが偽物かハッキングされたと思い込んで購入をやめ、『怪しく見えた』と周りに言います。
• 大口顧客のITチームが契約前のセキュリティスキャンを行い、自己署名や信頼されていない証明書を見つけてリスクと判定します。修正にお金がかからないことで商談が止まります。
• 証明書が古い署名方式や弱い鍵を使っており、最新のブラウザが警告を出し始め、セキュリティ監査で何年も推奨外だった暗号として減点されます。
• カード決済を扱っており決済事業者が再監査を行うと、弱い鍵や期限切れの証明書が決済セキュリティの規則に違反し、修正されるまでオンライン決済が凍結されます。

なぜ重要か。 証明書はウェブサイトのセキュリティの中で最も目に見える部分です。健全なときは見えず、壊れるとサイト全体を恐ろしい警告とともに巻き添えにし、顧客をまっすぐ競合へ追いやります。証明書の期限切れは予期せぬサイト停止の第1位の原因で、しかも完全に防げます。有効な証明書を取得するのは無料で、健全に保つのはほぼ自動更新に任せるだけです。

これは何か、平易に言うと

誰かがあなたのウェブサイトを訪れるとき、パスワードやカード番号を安心して入力するには2つのことが必要です。第一に、見知らぬ者が読めないよう接続が暗号化されていること。第二に（こちらは忘れられがち）、向こう側にいるのが本当にあなたのウェブサイトで、説得力のある偽物を立てた偽者ではないと訪問者のブラウザが確信できること。その両方を担うのがTLS証明書（しばしば『SSL証明書』と呼ばれます）です。

あなたのドメインの改ざん防止の身分証だと考えてください。認められた機関が発行し、あなたのドメイン名と有効期限が押印され、接続を暗号化する鍵を運びます。すべてが整っていれば、ブラウザは鍵マークを表示し、サイトは通常どおり読み込まれます。身分証に問題があると、ブラウザは訪問者を安心させるどころか正反対のことをします。実質的に*『このサイトは安全でないかもしれません』*という全画面の警告を出すのです。

この検査は、その身分証の健全性を、それぞれ独立に身分証を壊す4つの点で見ます：

• 有効で信頼されているか？ — 認められた機関が発行し、あなたの正確なドメインに一致し、自己署名でなく、期限切れでない。
• もうすぐ期限切れか？ — 失効した証明書はサイト全体を落とすからです。
• 強い方式で署名されているか？ — 古い署名アルゴリズムは偽造されうる。
• 鍵が十分に強いか？ — 弱い鍵は原理的に破られうる。

先に良い知らせを。健全な証明書を取得するのは無料で、健全に保つのはほぼ、人間が誰も覚えていなくてよいように自動更新に任せることです。

これが招きうる損失

• 週末の停止。 証明書が金曜の遅くに静かに期限を迎えます。走るはずだった更新が走りませんでした（サーバーが移った、スクリプトが壊れた、誰も気づかなかった）。土曜の朝には訪問者全員、そしてGoogleのクローラーが、ホームページの代わりに全画面の赤い警告を見ます。店は閉まっているのにあなたは知りません。技術的な修正は数分ですが、失った週末の売上と『廃業した』と判断した顧客は戻ってきません。

• 放棄された決済。 顧客がホテルのWi-Fiでスマホから買おうとしています。証明書が入力したドメインと完全には一致しません（例えばshop.yourbiz.comはカバーするが、入力した素のyourbiz.comはカバーしない）。ブラウザはサイトがあなたを『なりすましているかもしれない』と警告します。技術に詳しくない買い手にはそれが詐欺と読めます。タブを閉じ、あなたは商談があったことすら知りません。

• 止まった契約。 大口の見込み客のセキュリティチームが契約前に定例スキャンを行います。あなたのサブドメインのひとつに自己署名や信頼されていない証明書が見つかります。他がすべて問題なくても、その一つの危険信号が、迅速な承認を行ったり来たりに変え、商談を遅らせます—修正にお金がかからない問題のために。

• スローモーションの警告。 証明書は技術的には有効ですが、ブラウザが段階的に廃止してきた古い方式SHA-1で署名されています。ブラウザの更新ひとつで、一部の訪問者が、自分の最新マシンでは再現できない警告を見始めます。サイトが『壊れて見える』というサポート問い合わせがぽつぽつ届き、原因がわかりません。

• コンプライアンス違反。 カード決済を扱っています。再監査の際、決済事業者のチェックが弱い鍵や失効した証明書を指摘します。カードセキュリティの規則は強く現行の暗号化を要求するので、再発行するまでオンライン決済が停止され、最悪のタイミングで売上が凍結されます。

証明書の実体（4つの部分）

証明書は4つの異なる形で不健全になりえ、このページはそのすべてを扱います。内部ではそれぞれ別の検査ですが、あなたにとってはすべて『証明書は大丈夫か？』です。

1. 有効で信頼されている

これが最重要であり、証明書の健全性の中で唯一の致命的・最大比重の検査です。証明書が『有効で信頼されている』のは、以下がすべて真のときだけです：

• ブラウザがすでに信頼している認められた認証局（Let’s Encrypt、DigiCert、Sectigo、Google、Amazonなど）が発行した。
• 訪問者が使っている正確なドメインに一致する（サブドメインを含む）。www.yourbiz.comの証明書がyourbiz.comもカバーしないと、素のドメインで警告が出ます。
• 自己署名でない — つまり自分で自分に発行したものでない。暗号化はするが、あなたが誰かを何も証明しません。
• 現在その日付の範囲内 — 期限切れでなく、また（奇妙だが起こります）将来開始の日付でもない。
• 信頼の連鎖が無傷 — 署名した機関自身が信頼され、頂点まで連なっている。

このうちひとつでも欠ければ、ブラウザは恐ろしい『この接続ではプライバシーが保護されません』のページを出し、この検査はきっぱり不合格になります。良い状態とは、認められた機関の証明書が、あなたが実際に使うすべてのドメインとサブドメインをカバーし、日付に十分な余裕がある状態です。

2. もうすぐ期限切れにならない

すべての証明書には確固たる終了日があります。無料のものは通常90日、有料のものはしばしば1年。日付を過ぎると信頼は即座に消え、猶予期間はありません。この検査は残り日数と誰が発行したかとの関係を測ります：

• すでに期限切れ、または7日未満で期限切れになる場合は致命的とみなされます—更新が失敗した兆候です。
• 30日以内で期限切れになり自動管理でない場合は、今すぐ更新せよという警告です。
• 自動更新するプロバイダー（Let’s Encrypt、Cloudflare、Google、Amazon、ZeroSSLなど）で少なくとも1週間の余裕があれば合格します—期限前に自動更新されると期待されるからです。
• 十分な余裕（90日以上、または自動管理）はきれいな合格です。

良い状態とは、誰も触れずに自動更新する自動管理の証明書です。期限切れ停止を決して起こさない最も確実な方法は、更新の責任を人ではなく機械に負わせることです。

3. 強い署名アルゴリズム

すべての証明書は、ブラウザが改ざんを検知できるよう暗号アルゴリズムで『署名』されています。古いアルゴリズム（MD5とSHA-1）は偽造可能であることが示されており、攻撃者が原理的にあなたのもののように見える不正な証明書を作れます。この検査は、証明書が強く最新の署名（SHA-256以上（SHA-384、SHA-512）、最新のECDSA、Ed25519/Ed448）を使うとき合格します。MD5とSHA-1は不合格です。良い状態とはSHA-256以上で、これはすべての無料・最新の証明書の初期値なので、近年発行されたものでは問題になることはまれです。

4. 強い鍵

証明書は、実際に暗号化を行う暗号鍵を運びます。その鍵が短すぎると、十分な資源があれば最新の計算能力でそれを破り、攻撃者があなたのサイトになりすましたりトラフィックを復号したりできます。認められた最小は2048ビットRSAまたは**256ビット楕円曲線（EC）**です。この検査はそのサイズ以上で合格し、それ未満で不合格になります。良い状態とは2048ビット（または4096ビット）RSA、あるいはP-256のような256ビットECの鍵で、これもまた最新の無料証明書の初期値です。

後ろの3つについての注記：有効で信頼されているが警告ページを引き起こす致命的なものです。署名と鍵の強度は将来への備えと監査に関わります—最近の無料証明書はほぼ常に自動で合格しますが、セキュリティ審査が確認する項目なので、正しくしておく価値があります。

修正方法（無料・約15分）

ウェブサイトやホスティングを運用している人にこの項を渡してください。修正は無料です。 有効で強く自動更新する証明書は、Let’s Encryptやどの最新ホストでも費用がかかりません。当社が料金をいただくのは、それが健全な状態を保ち続けているかを監視する場合のみで、修正ではありません。IT担当がいない場合も、下のプラットフォーム別の注記でほとんどのオーナーはそこにたどり着けます。

ステップ1 — 無料で信頼された証明書を取得（または交換）する。 最新の無料証明書は初期状態でSHA-256と強い鍵を使うため、この一手で有効性・署名・鍵の強度がすべて一度に直ります。

• Cloudflare： SSL/TLS → Overviewでモードを**Full (Strict)**に設定。Cloudflareが信頼されたエッジ証明書を発行・自動更新します。『Strict』が機能するよう、オリジンサーバーにも有効な証明書があることを確認してください。
• Google Workspace / Microsoft 365 ホスティング、またはcPanelホスト： SSL/TLS Statusを探してAutoSSLを実行。無料証明書を自動で発行・更新します。
• サイトビルダー（Squarespace、Wix、Shopify、最新のWordPressホスト）： SSLは通常初期状態でオン。ドメイン／セキュリティ設定で有効になっているか、yourbiz.comとwww.yourbiz.comの両方をカバーしているか確認してください。
• 自前のLinuxサーバー（Nginx/Apache）： CertbotでLet’s Encryptをインストール—sudo certbot --nginx -d yourbiz.com -d www.yourbiz.com（または--apache）。最新のEC鍵には--key-type ecdsaを追加。-dで提供するすべてのホスト名を列挙し、証明書がそのすべてに一致するようにします。

ステップ2 — 二度と期限切れにならないよう更新を自動化する。 これが週末停止の筋書きを防ぐステップです。

• Let’s Encryptサーバーでは、更新タイマーが有効か確認しテストします：sudo certbot renew --dry-run。Certbotは通常自動タイマーをインストールしますが、なければ日次のcronを追加：0 3 * * * certbot renew --quiet。
• Cloudflare、cPanel AutoSSL、マネージド／サイトビルダーのホストでは、更新は任せられているので予定するものはありません。

ステップ3 — 正しい名前をカバーしているか確認する。 『有効だが警告』の最もよくある原因は名前の不一致です。証明書は顧客が実際に使うすべてのホスト名—素のドメイン、www、shop.やapp.などのサブドメイン—をカバーしなければなりません。証明書を生成するとき、それぞれを含めます（*.yourbiz.comのようなワイルドカードは全サブドメインを一度にカバーします）。

ステップ4 — 署名や鍵の強度だけが指摘された場合は、再発行するだけ。 何も買う必要はありません。新しい証明書を生成すれば（ステップ1）、新しいものは自動でSHA-256と強い鍵を使います。自前のサーバーでは最新の鍵を明示的に指定できます—例えばECならopenssl ecparam -genkey -name prime256v1 -out server.key、RSAならopenssl genrsa -out server.key 4096—として再発行します。

ステップ5 — 検証して、ここで再チェックする。 日付・発行者・鍵を手早く確認—echo | openssl s_client -servername yourbiz.com -connect yourbiz.com:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject—してから、この検査を再実行します。

よくある間違い

• 『一度SSLを入れた』で完了と扱う。 証明書は時計で期限切れになります。自動更新がなければ、問題はいつかではなくいつ失効するかであり、たいてい最も都合の悪いときです。
• wwwはカバーするが素のドメインはしない（または逆）。 両方が証明書に載っていなければ、片方が名前不一致の警告を出します。後から追加した新しいサブドメインも同じ罠にかかります。
• 実際は公開されている『テスト』サブドメインに自己署名証明書を残す。 暗号化はするので安全に感じますが、ブラウザ（とセキュリティスキャナー）は信頼されていないものとして扱い、監査の定番の危険信号です。
• 有料の方が安全だと思い込む。 無料のLet’s Encrypt証明書は高価なものとまったく同じくらい信頼され暗号化されます。多く払っても鍵マークが強くなるわけではありません。
• 証明書を更新したがサーバーの再読み込みを忘れる。 ディスク上の新しい証明書は、ウェブサーバーがそれを取り込むよう再読み込みされるまで何もしません—『更新したのにまだ期限切れと出る』の意外に多い原因です。
• 静かに失敗した自動更新。 更新ジョブは壊れることがあり（移動したファイル、DNSの変更、塞がれたポート）、静かに『成功』し続けます。更新ジョブだけでなく期限日を監視することが、これが噛みつく前に実際に捕まえる手段です。

よくある質問