Security+ Academy · レッスン

PKIのユースケース：HTTPS、S/MIME、コード署名

Webトラフィックの保護、S/MIMEによるメールの暗号化、コード署名証明書によるソフトウェアの完全性検証など、実際の場面でPKIの概念を活用します。

レッスン 4/413 ステップ

「PKIのユースケース：HTTPS、S/MIME、コード署名」はCoddyKit上の無料Security+ Academyレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはSecurity+ Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Security+ Academyコースには全4レッスンが含まれています。

実際のアプリケーションにおけるPKI

公開鍵基盤（PKI）は、安全なデジタル通信を支える、目には見えない基盤です。これまで学んできた証明書とCAは、日々、数多くの実際のシナリオで利用されています。Security+試験では、PKIのユースケースを見分け、それぞれに適した証明書の種類を理解し、各状況でPKIがどのような保護を提供するかを特定する能力が問われます。試験で特に重要な3つのユースケースは、HTTPS/TLS（Webセキュリティ）、S/MIME（メールセキュリティ）、コード署名（ソフトウェアの完全性）です。

HTTPS：WebセキュリティのためのPKI

HTTPS（TLS上のHTTP）は、最も分かりやすいPKIのユースケースです。https://bank.comに接続すると、ブラウザーは次の処理を行います。(1) サーバーのTLS証明書を受け取る、(2) 証明書チェーンが信頼されたルートCAにつながることを検証する、(3) SANフィールドとホスト名を照合する、(4) 証明書が失効していないことを確認する、(5) 公開鍵を使用したDiffie-Hellman鍵交換によって暗号化セッションを確立する。ブラウザーに表示される南京錠アイコンは、これらのチェックがすべて成功したことを示します。証明書がない場合や無効な場合、ブラウザーは警告を表示し、ほとんどのユーザーは先に進めなくなります。

# Check HTTPS certificate details
curl -v https://example.com 2>&1 | grep -A 10 'SSL certificate'

# Test TLS configuration quality
openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | \
  grep -E 'Protocol|Cipher|Verify'
# Protocol: TLSv1.3
# Cipher: TLS_AES_256_GCM_SHA384
# Verify return code: 0 (ok)

S/MIME：メールセキュリティのためのPKI

S/MIME（Secure/Multipurpose Internet Mail Extensions）は、PKI証明書を使用してメールに2つのセキュリティサービスを提供します。暗号化：送信者は受信者の公開鍵でメール本文を暗号化するため、受信者だけが復号できます。これにより、メールが転送中に傍受された場合や、侵害されたサーバーに保存されている場合でも機密性が保護されます。デジタル署名：送信者は自分の秘密鍵で署名します。これにより、メールが本当に送信者から送られたものであり、改ざんされていないことを受信者が確認できます。完全性が保護され、否認防止も実現されます。S/MIMEでは、各ユーザーがCAから発行された自分専用の証明書を持つ必要があります。

# S/MIME email signing and encryption with OpenSSL
# Sign an email
openssl smime -sign -in email_body.txt -signer alice_cert.pem \
  -inkey alice_private.key -out signed_email.eml -outform PEM

# Encrypt an email (using Bob's public key/certificate)
openssl smime -encrypt -aes256 -in email_body.txt \
  -out encrypted_email.eml bob_cert.pem

# Bob decrypts with his private key
openssl smime -decrypt -in encrypted_email.eml \
  -recip bob_cert.pem -inkey bob_private.key

コード署名：ソフトウェア完全性のためのPKI

コード署名は、PKIを使用して実行ファイル、スクリプト、ドライバー、インストーラーなどのソフトウェアにデジタル署名します。これにより、ユーザーはソフトウェアが信頼できる発行元から提供されたものであり、改ざんされていないことを確認できます。ソフトウェアベンダーは、信頼されたCAが発行したコード署名証明書の秘密鍵でコードに署名します。ユーザーがソフトウェアを実行すると、OSは証明書チェーンに含まれるベンダーの公開鍵を使用して署名を検証します。Windows SmartScreen、macOS Gatekeeper、iOS/Androidのアプリストアはいずれも、ソフトウェアの出所を確立するためにコード署名を利用しています。署名されていないソフトウェアはブロックされたり、セキュリティ警告が表示されたりする場合があります。

# Verify code signing on Windows (PowerShell)
Get-AuthenticodeSignature -FilePath 'C:\Software\installer.exe' | Format-List
# Status: Valid
# SignerCertificate: [certificate details]
# TimeStamperCertificate: [timestamp CA details]

# On Linux/macOS, verify GPG signature of downloaded software
gpg --verify hashicorp_public.gpg terraform.zip.sig terraform.zip
# Good signature from 'HashiCorp Security (hashicorp.com/security)'

クライアント証明書認証

クライアント証明書認証（相互TLSまたはmTLSとも呼ばれます）は、標準的なTLSモデルを拡張し、クライアントにも証明書の提示を要求します。標準的なTLSでは証明書によって認証されるのはサーバーだけですが、mTLSでは双方が相互に認証されます。これは、VPN認証（パスワードの代わりにスマートカードやクライアント証明書を使用する）、API認証（クライアントが人間ではなくサービスである場合のマシン間認証）、特権管理者アクセス（管理者に証明書を内蔵したハードウェアトークンの使用を要求する）などに利用されます。

# nginx configuration for mutual TLS (client certificate required)
# server {
#   listen 443 ssl;
#   ssl_certificate /path/to/server_cert.pem;
#   ssl_certificate_key /path/to/server_key.pem;
#   ssl_client_certificate /path/to/ca_cert.pem;
#   ssl_verify_client on;
#   ssl_verify_depth 2;
# }

# Test with a client certificate
curl --cert client_cert.pem --key client_key.pem https://api.example.com/

SSHホストキーの検証

SSHは、公開鍵暗号方式をサーバー認証とクライアント認証という2つの目的で使用します。サーバー認証では、SSHサーバーに初めて接続すると、サーバーはホストキー（公開鍵）を提示します。SSHクライアントはこれを~/.ssh/known_hostsに保存します。その後の接続でホストキーが変更されていると、MITM攻撃やサーバーの再構築を示している可能性があるため、SSHは警告を表示します。クライアント認証では、管理者はパスワードの代わりにキーペアを使用します。公開鍵をサーバーのauthorized_keysに追加し、送信されることのない秘密鍵によって本人であることを証明します。SSHホストキーはPKI証明書とは別のものですが、同じ信頼機能を果たします。

# First-time SSH connection stores server host key
ssh user@server.example.com
# The authenticity of host 'server.example.com' can't be established.
# ED25519 key fingerprint is SHA256:abc123...
# Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

# Host key stored in: ~/.ssh/known_hosts
cat ~/.ssh/known_hosts | grep server.example.com

# If host key changes: 
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

ドキュメント署名とタイムスタンプ

PKIにより、多くの国や地域で法的拘束力のあるデジタル文書署名が可能になります。Adobe PDFの署名、DocuSign、政府の電子署名システムはいずれも、PKI証明書を使用して文書に署名します。文書署名を補完する重要な仕組みがタイムスタンプです。Trusted Timestamp Authority（TSA）は、信頼できる時刻情報を付加して文書のハッシュに署名し、その文書が特定の時点で存在していたことを証明します。タイムスタンプはコード署名にも不可欠です。タイムスタンプがなければ、署名証明書の有効期限が切れた時点で、期限切れ前に配布されたソフトウェアであってもコード署名は無効になります。

IoTデバイス証明書

IoTデバイスが急速に増加する中、PKIは大規模にデバイスを認証する仕組みを提供します。各デバイスには製造時に固有の証明書がプロビジョニングされます（このプロセスをデバイスIDプロビジョニングと呼びます）。これにより、サーバーは証明書を使って個々のデバイスを認証できます。たとえば、スマートメーターが電力会社のサーバーに対して自身のIDを証明する、医療機器が病院ネットワークに対して認証する、車両群がメーカーのバックエンドに対して認証する、といったシナリオが可能になります。IoT向けPKIでは、リソースに制約のある環境で数百万台のデバイスを処理する必要があるため、サイズが小さく検証が高速なECC証明書の採用が進んでいます。

証明書を使用したVPN認証

証明書ベースのVPN認証は、パスワードベースのVPN認証よりも大幅に安全です。各VPNユーザーまたはデバイスには、組織の内部CAからクライアント証明書が発行されます。接続時にVPNゲートウェイはクライアント証明書を検証します。検証では、信頼された内部CAによって発行されたこと、有効期間内であること、CRL/OCSPによって失効していないことを確認します。従業員が退職した場合、その証明書を失効させることでVPNアクセスを直ちに防止できます。これは、従業員がパスワードを他人と共有していないことを期待するよりも確実です。

# OpenVPN client certificate configuration
# client
# remote vpn.example.com 1194
# proto udp
# ca ca.crt        <- CA certificate (trust anchor)
# cert client.crt  <- Client's certificate
# key client.key   <- Client's private key
# tls-auth ta.key 1
# cipher AES-256-GCM

# The VPN server verifies the client cert chain against ca.crt
# Revoked certs listed in CRL won't be accepted

証明書に関する一般的なエラー

セキュリティ専門家は、一般的な証明書エラーを診断できなければなりません。証明書の期限切れ：notAfterの日付を過ぎています。証明書を更新します。ホスト名の不一致：証明書のSANが要求されたホスト名と一致していません。CNとSANを確認し、ワイルドカード証明書またはマルチSAN証明書が必要になる場合があります。自己署名証明書：この証明書を保証するCAがありません。ローカルの信頼ストアに追加するか、CA署名証明書に置き換えます。不完全なチェーン：中間CA証明書がサーバーから提供されていません。完全なチェーンを送信するようサーバーを設定します。証明書の失効：CRLまたはOCSPが失効を示しています。直ちに鍵侵害への対応が必要です。

# Diagnose certificate errors with openssl
openssl s_client -connect server.example.com:443 2>&1
# Common error messages:
# depth=0 ... error 10 at 0 depth lookup: certificate has expired
# depth=0 ... error 18: self-signed certificate
# depth=0 ... error 20: unable to get local issuer certificate (broken chain)
# depth=0 ... error 23: certificate revoked
# Verify return code: 0 (ok) = success

ワイルドカード証明書とSAN証明書

複数のホスト名には、2種類の証明書を使用できます。ワイルドカード証明書は、ドメイン直下にあるすべてのサブドメインを対象にします。*.example.comはwww.example.com、mail.example.com、api.example.comを対象にしますが、sub.api.example.com（2階層下）は対象にしません。すべてのサービスで1枚の証明書と1つの秘密鍵を使えるため便利ですが、鍵が侵害されるとすべてのサービスが影響を受けるというリスクがあります。マルチSAN証明書は、SAN拡張機能に複数の特定ドメイン（例：example.com、www.example.com、api.example.com）を明示的に列挙します。より細かく管理できますが、新しいドメインを追加するたびに証明書を更新する必要があります。

クイックチェック

このレッスンで扱ったCompTIA Security+（SY0-701）の概念について、理解度を確認しましょう。

対話的なレッスンで答える

レッスンのまとめ

このレッスンでは、HTTPS/TLSがサーバー証明書を使用してWebトラフィックを暗号化し、サーバーを認証すること、S/MIME証明書によってメールの署名と暗号化が可能になること、コード署名証明書によってソフトウェアの完全性と発行元の身元を証明できること、そしてクライアント証明書によってVPNやAPIの相互認証が可能になることを学びました。次はパスワードポリシーと多要素認証について学びます。

無料で開始

AI チューターと学ぶ Security+ Academy — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 30
レッスン: 120

無料で学習を始めるコース全体を表示

よくある質問

「PKIのユースケース：HTTPS、S/MIME、コード署名」レッスンは無料ですか？

はい。「PKIのユースケース：HTTPS、S/MIME、コード署名」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Security+ Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Security+ Academyコースには全4レッスンが含まれています。

「PKIのユースケース：HTTPS、S/MIME、コード署名」で何を学びますか？

Webトラフィックの保護、S/MIMEによるメールの暗号化、コード署名証明書によるソフトウェアの完全性検証など、実際の場面でPKIの概念を活用します。ブラウザで直接実行するハンズオンコードでSecurity+ Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Security+ Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSecurity+ Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「PKIのユースケース：HTTPS、S/MIME、コード署名」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecurity+ Academyレッスンでコードを書いて実行できますか？

はい。すべてのSecurity+ Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Security+ Academyに戻る