認証局（CA＝Certificate Authority）は、デジタル証明書を発行し、「この公開鍵は確かにこの相手のものだ」と保証する組織や仕組みです。HTTPS が成立しているのは、利用者のブラウザが特定の認証局を信頼しているという前提があるからです。
まず押さえたいポイント
- デジタル証明書 を発行する側
- 署名によって
この公開鍵はこの主体のものと示す - ブラウザや OS は、信頼する認証局をあらかじめ持っている
どんな場面で使うか
- Web サイトの HTTPS 証明書発行
- 社内 PKI での端末証明書発行
- メール署名やコード署名の証明書発行
どんなふうに理解するとよいか
初心者向けには、証明書にお墨付きを与える立場 と考えると分かりやすいです。
ただし、どの認証局でも無条件に信頼されるわけではなく、利用者側がその認証局を信頼していることが前提です。
押さえておきたい注意点
認証局が信頼の起点になるので、チェーン設定や失効情報、発行ポリシーも大事です。
証明書がある ではなく どの認証局が、どの条件で発行したか まで見る必要があります。
信頼はどうつながっているか（証明書チェーン）
信頼は鎖のようにつながっています。
ルート認証局（ブラウザやOSに最初から埋め込まれている）→ 中間認証局 → サーバー証明書
ブラウザは、サーバー証明書から順にたどって信頼済みのルートに行き着くかを確認します。ルートCAの秘密鍵は極めて重要なので、普段は使わず中間CAが実務の発行を担うという構造になっています。
実務で最も多いトラブルが「中間証明書の設定漏れ」です。証明書自体は正しくても鎖が途切れるため信頼をたどれず、エラーになります。厄介なのはブラウザによっては中間証明書を補完して正常に見えることがある点で、「自分の環境では見られるのに、一部の人だけエラー」という症状になります。
実務で見るポイント
公開サイトでは一般に信頼されたCA（Let’s Encrypt など）を使い、社内システムでは社内CAを立てることもあります。ただし社内CAの証明書は各端末に「信頼する」設定を配らないと警告が出ます。
もう一つ重要なのが失効です。秘密鍵が漏れた証明書は失効させる必要がありますが、失効情報が確実に伝わる保証は弱いのが実情で、これも証明書の有効期間が短くなっている背景のひとつです。証明書全体の役割は デジタル証明書とは を参照してください。