はじめに
目的
本ドキュメントは、SSL/TLS通信で用いる自己署名証明書（自己証明書）の基本的な理解と実装方法を分かりやすくまとめたものです。開発や検証、簡易な環境での利用を想定して説明します。
対象読者
・開発者や運用担当者
・セキュリティの基礎を学ぶ方
・自己署名証明書を使ってみたい学習者
専門的な暗号理論を深く知らなくても読み進められるよう配慮しています。
本書で学べること
・自己署名証明書の定義と特徴
・正式な認証局発行証明書との違い
・利用シーンとリスク
・作成手順や有効期間の扱い
・開発環境でのブラウザ警告回避と本番での推奨対策
読み方
各章は独立して読めますが、順に読むと理解が深まります。実際に作成する際は第6章を手順書として参照してください。
自己署名証明書の定義と基本概念
定義
自己署名証明書（Self-Signed Certificate）は、認証局（CA）を通さずに自分で作成し、自分で署名したSSL/TLS証明書です。日本では「オレオレ証明書」と呼ばれることもあります。第三者の検査が入らないため、証明書の発行元を外部が保証しません。
仕組み（簡単な例）
- まず秘密鍵と公開鍵のペアを作ります。
- 公開鍵に対して証明書の情報（組織名や有効期限など）を付けます。
- 自分の秘密鍵でその情報に署名します。これが自己署名証明書です。
通信は公開鍵で暗号化できるため、データの盗聴対策にはなりますが、相手が本当に正しい相手かを外部で確認する仕組みはありません。
利点
- 無料で即座に発行できます。テスト環境や内部システムで手間が少なく使えます。
- 外部の認証局に依存しないため、短期間の用途や実験に向きます。
注意点（信頼性と安全性）
- ブラウザやOSはデフォルトで信頼しないため警告が出ます。
- 中間者攻撃（偽の証明書で通信を傍受される）などのリスクが高まります。
- 本番公開のサービスでは、第三者による検証がある正式な証明書を使うべきです。
利用の目安
開発・検証や社内限定のサービスなら実用的ですが、外部公開や決済など機密性が高い用途には向きません。具体的な使いどころは次章以降で詳しく説明します。
正式な証明書との主な違い
発行元と信頼の仕組み
自己署名証明書は発行者が自分自身です。正式な証明書は第三者の認証局（CA）が発行し、組織の身元を確認します。認証局は多くのブラウザやOSに「信頼された発行者」として登録されているため、利用者側で自動的に信用されます。
ブラウザや利用者の扱い
正式な証明書はブラウザが安全と判断し、警告を表示しません。自己署名証明書は多くの場合、接続時に警告やエラーが出ます。たとえば、サイトへ初めてアクセスしたときに「接続は保護されていません」と表示されることがあります。
用途の違い（具体例）
- 自己署名：開発用のローカルサーバー、社内テスト環境、短期間の検証。設定が簡単で即座に使えます。
- 正式な証明書：公開ウェブサイト、顧客向けサービス、決済や個人情報を扱う場面。利用者の信頼を得る必要がある場合に適します。
コストと手間
自己署名は無料で発行できます。正式な証明書は有料かつ発行に手続きが必要ですが、無料の認証局（例：Let’s Encrypt）もあります。証明書の管理や更新は正式なものほど厳密な運用が求められます。
セキュリティとなりすまし対策
正式な証明書は認証局が身元確認を行うため、なりすましのリスクを低くします。自己署名は発行者の信頼を第三者が保証しないため、攻撃者がなりすます可能性があります。とはいえ、暗号技術自体はどちらも同じ方式を使えるため、用途に応じた選択が重要です。
自己署名証明書の適切な利用シーン
ローカル開発環境
ローカルマシンでの開発や動作確認に最適です。ブラウザやクライアントに手動で証明書を信頼させるだけで、HTTPSを使った通信を簡単に試せます。公開鍵や暗号の動作確認、プロトタイプ作成に向きます。
社内テストサーバー／ステージング
外部公開しない社内ネットワーク上のサーバーでは実用的です。機能テストや統合テスト、QA環境で使うとコストを抑えられます。アクセスを社内に限定し、証明書の配布を管理すれば安全性を確保できます。
自動化テスト・CI環境
自動テストや継続的インテグレーションのジョブ内で、テスト用に一時的に自己署名証明書を生成して使うことが多いです。テストスイート内で信頼設定を行えば、繰り返しのテストがスムーズになります。
開発用のOAuthコールバックやWebhooks
外部サービスを使う開発段階で、コールバック先やWebhookの受け口をローカルや社内サーバーにする場合に有効です。事前に相手側に証明書を登録したり、開発用のドメインで限定して使うと便利です。
IoT・組み込み機器の内部通信
閉じたネットワーク内で機器同士が通信するケースでは、自己署名証明書で暗号化を行うことがあります。大量デバイスの一括導入や、外部からの接続を遮断した環境で有効です。
運用上の注意（簡単に）
自己署名証明書は公開サービス向けには推奨しません。短期間だけ使う、信頼する範囲を限定する、証明書の配布と管理を厳密に行う――この三点を守ると安全に活用できます。
自己署名証明書のセキュリティ上の脆弱性と危険性
概要
自己署名証明書は外部の認証機関（CA）に確認されません。そのため、利用者側は有効な正規証明書と偽の証明書を見分けられない可能性があります。ここでは主なリスクを具体例とともに説明します。
中間者攻撃（MITM）のリスク
攻撃者が通信の途中に入れる環境（公共のWi‑Fiなど）で、攻撃者自身の自己署名証明書を提示すると利用者は警告を無視して接続することがあります。すると攻撃者は通信内容を傍受・改ざんできます。簡単に言えば、通信の中身を盗まれる恐れが高まります。
なりすましと信頼性の欠如
自己署名では発行元の身元確認が行われないため、攻撃者がサービスになりすますのが容易です。ログイン情報や個人情報を入力させられる危険があります。組織外のユーザーには信頼できないと判断されやすいです。
ブラウザ警告とユーザー体験の低下
主要なブラウザは自己署名証明書を不審と判断し、警告画面を出します。多くの利用者は警告を見て離脱するため、サービスの信用や利用率が下がります。したがって本番利用には適しません。
運用上の懸念
自己署名証明書は取り消し（リボーク）や第三者による監査が難しく、有効期限管理や更新の過程でヒューマンエラーが起きやすいです。結果として長期的なセキュリティ維持が困難になります。
注意点
開発や限定された内部環境での短期利用に留め、外部向けや機密性の高い通信には正式な証明書を使うことを強く推奨します。
自己署名証明書の作成方法
以下はOpenSSLを使った、基本的な自己署名証明書の作成手順です。実例コマンドも付けてわかりやすく説明します。
1) 秘密鍵を作る
2048ビットのRSA鍵を生成します。安全のためファイル権限を制限してください。
openssl genpkey -algorithm RSA -out privkey.pem -pkeyopt rsa_keygen_bits:2048
chmod 600 privkey.pem
2) 証明書署名要求（CSR）を作る
サーバ名（Common Name＝CN）を指定してCSRを作成します。例: example.local
openssl req -new -key privkey.pem -out server.csr -subj “/CN=example.local”
3) 自己署名証明書を作る
CSRを使って有効期間365日の自己署名証明書を作成します。
openssl x509 -req -in server.csr -signkey privkey.pem -days 365 -out server.crt
ワンコマンドで作る方法
パスフレーズなしで一度に作る例:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privkey.pem -out server.crt -subj “/CN=example.local”
SAN（Subject Alternative Name）について
ブラウザで警告を避けたい場合、CNだけでなくSANにドメインやIPを含める必要があります。extfile.cnfを用意して
subjectAltName=DNS:example.local,IP:127.0.0.1
を指定し、opensslコマンドに-extfileと-extensionsを渡してください。
鍵の扱いと確認
秘密鍵は厳重に保管し、自動化で使う場合はパスフレーズの扱いに注意します。作成後はopenssl x509 -in server.crt -text -nooutで内容を確認してください。
自己署名証明書の有効期間と仕様
有効期間の一般的な目安
自己署名証明書の有効期間は、生成時に設定できます。実務では生成から約27か月（約2年3か月）を目安にすることが一般的です。これは公開（認証局）発行証明書の運用に合わせた目安で、自己署名でもこの範囲を採ることが多いです。
OpenSSLでの指定方法
OpenSSLでは「-days」オプションで有効日数を指定します。例えば1年なら365、27か月なら約825日（27×30.4日）を指定します。コマンド例:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 825 -nodes
このオプションは証明書の「notBefore」と「notAfter」を設定します。
推奨と注意点
- 開発用: 長め（数年）にして運用を簡単にできます。ローカル環境や閉域環境なら許容されます。
- 本番風景（公開サービス）: 短め（1年以内または組織ルールに準拠）を推奨します。期限が長いと鍵が漏れたときの影響が大きくなります。
期限切れの影響: ブラウザやクライアントは期限切れを厳しく扱い、警告や接続拒否を出します。自動更新や管理台帳で期限を把握してください。
運用上の工夫
- 自動更新スクリプトを用意する
- 鍵のローテーション頻度を決める
- 有効期間とリスク（鍵管理状況）を照らし合わせて決定する
この章では実務で決めやすい目安と注意点を示しました。
開発環境でのブラウザ警告回避方法
概要
ローカル開発でブラウザの「安全でない接続」警告を避けるには、ローカル用の信頼できる認証局（CA）を作り、そのCAで発行した証明書を使います。代表的な方法にmkcertの利用や、開発ツールのユーザー用CAをOSの信頼ストアに追加する手順があります。
mkcertを使う手順（代表例）
- mkcertを導入します（Homebrewやchocolatey、配布バイナリなど）。
- mkcert -install を実行してローカルCAを作成し、OSの信頼済みストアに登録します。
- mkcert localhost 127.0.0.1 ::1 のようにコマンドを実行して、ローカル用の証明書と鍵を発行します。
- 発行されたcertとkeyを開発用サーバに設定します（例：Nodeではhttps.createServer({ key, cert }, app)）。
- ブラウザを再起動すれば、警告なしでアクセスできます。
mkcertは多くの手順を自動化しますが、Firefoxは独自の証明書ストアを使うため、必要ならFirefoxに手動でCAをインポートしてください。
開発ツール付属のCAを使う場合
ServBayなど一部のツールはユーザー用CAを生成します。手順は一般に次の通りです：ツールからCAファイルをエクスポート→OSの信頼ストアにインポート（macOSはキーチェーン、Windowsは証明書スナップイン、Linuxはディストリビューションの方法）→ブラウザ再起動。
注意点
- ローカルCAは管理者権限での登録が必要です。権限に注意してください。
- CA鍵は厳重に保管し、不要になったら信頼ストアから削除してください。誤って公開すると危険です。
- 本番環境では公開CAの証明書を使ってください。
本番環境での推奨される対策
信頼された認証局の利用
本番では必ず公開の信頼された認証局（CA）発行の証明書を使います。Let’s Encryptのような無料CAも運用に十分使えます。ブラウザ警告を避け、ユーザーの信頼性を保てます。
発行と更新の自動化
証明書の期限切れはサービス停止につながります。CertbotやACMEクライアントで取得・自動更新を設定してください。更新失敗のアラートを仕込みます。
TLS設定の最適化
TLSバージョンはTLS1.2以上を有効にし、古い暗号は無効化します。安全な優先順位（エリプティック曲線やAEAD暗号）を設定し、プロトコルの脆弱性対策を適用します。
追加の安全措置
OCSPステープリングを有効にして応答性を改善します。中間証明書を正しく連結して配信してください。HSTSを導入してHTTPからの降格を防ぎます。
鍵管理とインフラ
秘密鍵は適切に保護します。可能ならHSMやクラウドの鍵管理サービスを使ってください。CDN利用時は証明書の配置方法を確認します。
運用監視と検査
証明書の有効期限監視、CTログや脆弱性スキャンを定期実施します。証明書ピンニングは慎重に運用してください。
