SSLと自己署名証明書の基礎知識と運用ポイント完全解説

2025 9/28

2025/09/28

はじめに

この章では、本記事の目的と読み進め方をわかりやすく説明します。

この記事の目的

本記事は「自己署名証明書（SSL/TLSの自己署名）」について、基礎から実務での使い方までを丁寧に解説します。初心者の方でも理解できるよう専門用語は最小限にし、具体例を交えて説明します。

誰に向けた記事か

社内や開発環境で暗号化通信を設定したいエンジニアや管理者
自分で証明書を作って試したい学習者
小規模なシステムでコストを抑えたい運用担当者

本記事で学べること

自己署名証明書の意味と特徴
利用シーンと具体例
作成方法の手順と注意点
メリット・デメリットと安全な運用方法

まずは基礎を押さし、その後で実務に使える知識を順に学んでいきましょう。

自己署名証明書とは何か

定義

自己署名証明書（Self-signed certificate）は、公開鍵を自分自身の秘密鍵で署名した証明書です。通常のSSL/TLS証明書は認証局（CA）が発行・署名しますが、自己署名証明書はサイト運営者や開発者が自分で作成します。

仕組み（簡単な流れ）

鍵ペア（公開鍵と秘密鍵）を作成します。
公開鍵と組織名などの情報を証明書に入れます。
その証明書に対して自分の秘密鍵で署名します。
暗号理論上は、署名によって当該秘密鍵を持っていることを証明できます。

公的信頼との違い

自己署名証明書は第三者による実在性の保証がありません。つまり、ブラウザやOSが「信頼できる発行者」として認めないため、アクセス時に警告が出ます。対してCA発行の証明書は認証局が身元確認を行い、広く信頼されます。

具体例

ローカル開発環境でHTTPSを試すとき
社内ネットワークのテストサーバー
これらでは手軽に暗号化を試せる利点があります。

注意点

自己署名証明書は便利ですが、公開サービスでそのまま使うと利用者に警告が表示されます。信頼性が必要な公開サイトではCA発行の証明書を使うことをおすすめします。

自己署名証明書の利用シーン

概要

自己署名証明書は主に開発や内部向けで使います。公式な認証局を通さないため費用がかからず、素早くHTTPSを試せます。外部公開の本番サイトには基本的に向きません。

具体的な利用シーン

ローカル開発環境：MAMP、XAMPP、Docker上のWebアプリでHTTPSを確認するときに使います。ブラウザの警告は出ますが動作検証に便利です。
テスト環境・ステージング：機能テストや表示確認、APIの通信テストなどで本番に近い条件を再現できます。
社内イントラネット：社外公開しない社内ポータルや管理画面では、社内の信頼設定で安全に使えます。
自動テスト・CI：テストサーバで証明書の発行・削除を自動化し、テストパイプラインを簡潔に保てます。
組み込み機器・IoT：開発段階でのHTTPS通信確認や、製造過程での検証に向きます。

導入時のポイント

ブラウザは警告を出すため、利用者に事前説明や手順を用意してください。
社内利用なら証明書を配布して信頼させる必要があります（管理負担が増えます）。
有効期限を短くして定期的に更新する運用が安全です。

以上が代表的な利用シーンです。用途とリスクを整理して使ってください。

自己署名証明書の作成方法

自己署名証明書はOpenSSLなどで簡単に作れます。ここではWindows環境での手順例を分かりやすく説明します。

事前準備

OpenSSLをインストールし、コマンドプロンプトからopensslが使えることを確認します。
作業用フォルダを作成し、そこにファイルを置きます。

SAN（Subject Alternative Name）ファイルの作成例

テキストファイル（例：san.txt）に以下を記載します。

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = example.local
IP.1 = 192.168.0.10

上のexample.localやIPは実際のホスト名やIPに置き換えてください。

コマンド例（順番に実行）

1) 秘密鍵を作成
openssl genrsa -out mykey.key 2048

2) CSRを作成（CNは任意）
openssl req -new -key mykey.key -out mycsr.csr -subj “/CN=example.local”

3) 自己署名証明書を発行（SANを付与）
openssl x509 -req -in mycsr.csr -signkey mykey.key -out mycert.crt -days 365 -extensions v3_req -extfile san.txt

4) 必要ならPFXに変換（Windowsのサーバで使う場合）
openssl pkcs12 -export -out mycert.pfx -inkey mykey.key -in mycert.crt

ファイル配置とサーバ設定

秘密鍵（mykey.key）は厳重に保管し、アクセス権を制限します。
証明書（mycert.crt）と鍵をWebサーバ（IIS, Apache, Nginxなど）に設定します。IISでは.pfxをインポートしてサイトにバインドします。

注意点

クライアント側で証明書を信頼させる必要があります。社内システムなら配布して信頼済みにしてください。したがって公開環境では認証局発行の証明書を検討してください。

以上が基本的な作成手順です。実際の環境に合わせてファイル名やパス、CN/SANを調整してください。

自己署名証明書のメリット

概要

自己署名証明書は自分で発行する証明書です。認証局に頼らずに無料で作成でき、即時に使い始められる点が最大の利点です。

コストと手間の削減

費用がかかりません。予算を気にせず複数の環境で使えます。申請や承認の手続きも不要で、発行・更新を自動化できます。

開発・テストでの速さ

ローカル開発や社内テストで素早くTLSを検証できます。たとえば、ローカルサーバーやCI環境で実際の暗号通信を試す際に便利です。

暗号化の確保

自己署名でもTLSの暗号化自体は有効です。通信内容は暗号化され、中間者攻撃の防止に役立ちます。

柔軟な運用

有効期限や識別名（SAN）を自由に設定できます。テスト用証明書を短期間で発行したり、複数のホストで使う設定にできます。

主な利用場面

・ローカル開発、社内検証
・CI/CDの自動テスト
・限定された社内システムや実験的なサービス

これらの点により、短期的な検証やコストを抑えたい場面で特に有効です。

自己署名証明書のデメリット・注意点

ブラウザやOSの警告

自己署名証明書は、標準の信頼リストに登録されていません。そのためブラウザやOSが「安全ではない」「接続を続けますか」といった警告を表示します。ユーザーは不審に感じ、サービスの信頼性が損なわれる可能性があります。

実在性や改ざん防止の保証が弱い

第三者の署名がないため、その証明書が本当に意図した提供者のものかを自動で保証できません。悪意ある第三者が同様の証明書を使えば、中間者攻撃（通信を傍受・改ざんされる危険）を招きます。公開サービスでは重大なリスクです。

公開環境には不向き

外部の利用者がいる公開サービスでは使わないでください。利用者側に証明書を手動で受け入れさせる必要があり、手間と安全性の問題が残ります。代わりに認証局（CA）発行の証明書を検討してください。

管理上の注意点

有効期限を厳密に管理してください。期限切れになると接続ができなくなります。秘密鍵は厳重に保管し、漏えいがあれば直ちに更新してください。社内で使う場合でも、配布方法や自動更新の仕組みを用意すると運用負担が軽くなります。

互換性と運用の現実

一部のアプリやデバイスは自己署名をそもそも受け付けません。スマホアプリや外部APIとの連携時に障害になることがあります。内部利用に限定する場合は、配布手順と例外の扱いをあらかじめ整備してください。

以上を踏まえ、自己署名証明書は便利な一方で公開用途や長期運用には向いていません。社内や開発環境で使う際も運用ルールと管理体制を整えることをおすすめします。

自己署名証明書と認証局発行SSL証明書の違い

概要

自己署名証明書はサイト運営者自身が発行する証明書です。無料で作成でき、開発環境や社内サービスでよく使います。認証局（CA）発行のSSL証明書は、公的な認証機関が発行します。ブラウザやOSに信頼され、公開Webサービスに向きます。

主な比較ポイント

信頼性：CA発行はブラウザが標準で信頼します。自己署名は初回に警告が出るため、利用者が手動で信用設定する必要があります。例：社内のテストサーバーは自己署名で十分です。公開サイトはCA発行が安全です。
費用と手続き：自己署名は無料で即時発行できます。CA発行は無料のものもありますが、組織名確認など手続きが入り、発行に時間がかかる場合があります。
有効期限と更新：CA発行証明書は短期間での更新が求められる傾向にありますが、自動更新ツールが使えます。自己署名は期限を自由に設定できますが、更新管理は手動になります。

どちらを選ぶか

内部利用や短期テストなら自己署名でコストと手間を抑えられます。一般公開や外部ユーザーを相手にする場合は、ブラウザの警告を避けるためCA発行のSSL証明書を選ぶのが無難です。