SSL証明書
>#wip
SSL証明書とは
認証局（CA: Certificate Authority）が発行し、以下を保証します。
1. 通信の暗号化:
サーバとクライアント間のデータを暗号化し、盗聴や改ざんを防ぎます。
2. 認証:
サーバが正当な運営者であることを証明します。
3. データの完全性:
データが途中で改ざんされていないことを確認します。
SSL/TLSの暗号化の仕組み
SSL/TLSは主に2種類の暗号方式を組み合わせています。
1. 公開鍵暗号方式:
公開鍵（サーバが提供）と秘密鍵（サーバが保持）を使ってデータを暗号化/復号します。
公開鍵で暗号化したデータは対応する秘密鍵でのみ復号可能。
通信の初期段階で使用されます。
2. 共通鍵暗号方式:
サーバとクライアントで共有する「共通鍵」を使ってデータを暗号化/復号します。
高速なデータ通信に使用されます。
SSL/TLS通信の流れ
TLSハンドシェイク（鍵交換）:
クライアント（ブラウザ）がサーバに接続を要求。
サーバはSSL証明書と公開鍵をクライアントに送信。
SSL証明書は何に使うの #??
クライアントは公開鍵を使って共通鍵を暗号化して送信。
共通鍵はクライアントが生成する
共通鍵そのものは公開鍵で暗号化されるため、奪取されても大丈夫
秘密鍵が漏洩してなければ
サーバは秘密鍵を使って共通鍵を復号。
共通鍵でデータを暗号化して、その共通鍵自体も暗号化するってことか
3. SSL証明書の種類
SSL証明書には以下の種類があります。用途やセキュリティレベルに応じて選択します。
1. ドメイン認証（DV: Domain Validation）:
ドメインの所有者であることを証明。
Let's Encryptが提供する証明書はこれに該当。
2. 組織認証（OV: Organization Validation）:
ドメイン所有者に加え、運営組織の存在を証明。
会社名などが証明書に記載されます。
3. 拡張認証（EV: Extended Validation）:
より厳格な審査を経て発行。
ブラウザのURLバーに企業名が表示される（例: 銀行やECサイト）。
4. ワイルドカード証明書:
サブドメインをまとめてカバー（例:
*.example.com ）。5. マルチドメイン証明書:
複数の異なるドメインをカバー。
---
4. SSL証明書の発行フロー
ステップ 1: CSR（証明書署名要求）の生成
1. サーバで「秘密鍵」と「公開鍵」を生成。
2. 公開鍵とドメイン情報を含むCertificate Signing Request (CSR)を作成。
CSRには組織名、ドメイン名、所在地などが含まれます。
ステップ 2: 認証局(CA)への申請
1. CSRを認証局（CA）に送信。
2. CAが申請内容を確認し、ドメインや組織の所有者を認証。
ドメイン認証では、メール確認やDNSレコードの設定を要求。
組織認証や拡張認証では、書類提出が必要。
認証局の存在意義がよくわからない #??
何を認証しているのか
何を審査してるのか
逆に何がダメだったら審査に落ちるのか
例えば、ここがデタラメの情報だったりするとどう問題になるのか
自動化できないのか
ステップ 3: 証明書の発行
1. CAが審査を通過すると、SSL証明書が発行される。
2. サーバに証明書をインストール。
ステップ 4: サーバ設定
1. サーバソフトウェア（Apache, Nginx, etc.）でSSL証明書を設定。
2. HTTPS通信を有効化。
ステップ 5: 更新作業
SSL証明書は有効期限があるため（通常90日～2年）、期限前に更新が必要。
Let's Encryptなど無料証明書は自動更新ツール（Certbotなど）が利用可能。
5. SSL証明書の技術的要素
鍵のサイズ
公開鍵と秘密鍵には、RSAやECDSAが使われます。
鍵サイズ（ビット長）が長いほど安全性が高いが、計算コストが増加します。
RSA: 2048ビットが一般的。
ECDSA: より短い鍵で高い安全性を提供。
SSL証明書は「証明書チェーン」という構造で信頼性を確保します。
1. エンドエンティティ証明書（サーバ証明書）:
サーバに設定される証明書。
2. 中間証明書:
CAがエンドエンティティ証明書を発行したことを証明。
3. ルート証明書:
ブラウザやOSが信頼する証明書。
証明書チェーンが正しく構築されていないと、ブラウザが警告を表示することがあります。
---
6. SSL証明書とセキュリティの注意点
鍵管理
秘密鍵は絶対に漏洩してはいけません。
漏洩した場合、SSL証明書を直ちに失効（revoke）し、新しい証明書を発行する必要があります。
秘密鍵を奪取した人はどういう攻撃が可能なのか?
共通鍵を複合できるので、通信内容を傍受できてしまう
証明書の有効期限
有効期限切れの証明書を使用すると、ブラウザが警告を表示し、ユーザーの信頼を失う可能性があります。
HTTPS強制
サイトを完全にHTTPS化するには、HTTPからHTTPSへのリダイレクトを設定します。
3. 認証局(CA)（CA: Certificate Authority）の存在意義
何を認証しているのか
認証局は、以下の2つを保証します。
1. サーバの正当性:
サーバが偽装されていないことを証明。
例: サイトが実際に「example.com」の運営者によって管理されていること。
2. 運営者の身元（OV/EV証明書の場合）:
サーバを運営する組織が実在し、正規の運営者であることを証明。
何を審査しているのか
認証局は証明書を発行する前に以下を審査します。
1. ドメインの所有権（DV証明書の場合）:
サーバの管理者が実際にそのドメインを所有または管理しているか。
審査方法:
ドメインのDNSに指定のレコードを設定。
認証メールへの応答。
2. 組織の実在性（OV/EV証明書の場合）:
証明書申請者が実在する組織であること。
審査方法:
公的な企業情報（登記簿など）の確認。
電話や書類での本人確認。
逆に何がダメだったら審査に落ちるのか
不一致:
ドメインの所有権が確認できない。
登録された組織情報が虚偽または不完全。
信頼性の欠如:
提出書類が不正確。
電話確認や書類確認に応答しない。
ここがデタラメの情報だったりするとどう問題になるのか
フィッシング詐欺:
攻撃者が正当なサイトになりすまして証明書を取得すると、ユーザーが偽サイトを本物だと信じてしまう。
例: 銀行の偽サイトでログイン情報を盗む。
データの傍受・改ざん:
攻撃者が通信を傍受し、安全な通信を装って悪意ある行為を行う。
人が認証しているのか、自動化できないのか
ドメイン認証（DV証明書）:
大部分が自動化されています（DNS設定やメール認証）。
組織認証（OV/EV証明書）:
人の手による審査（書類確認や電話確認）が必要。
企業や団体の実在性を確認するために、完全な自動化は難しい。
4. 秘密鍵の重要性
秘密鍵を奪取した人はどういう攻撃が可能になるのか
秘密鍵が漏洩すると、以下の攻撃が可能になります。
1. 通信の復号:
攻撃者は共通鍵を復号できるため、クライアントとサーバ間の通信内容を傍受できます。
例: クレジットカード情報、パスワード。
2. なりすまし攻撃:
攻撃者が秘密鍵を使って偽のサーバを立ち上げ、クライアントを騙す。
例: フィッシングサイトの運営。
3. 改ざんしたデータの署名:
攻撃者が秘密鍵を使って改ざんしたデータに正当な署名を行い、サーバが送信したように見せかける。
---