🐈

【認証】RHEL9.6 / rsyslog で TLS を理解するためのたとえ話

に公開
TLS
認証
自己署名
tech

RHEL9.6 / rsyslog で TLS を理解するためのたとえ話

RHEL9.6 / rsyslog で TLS を使ったログ送信環境を作ろうとすると、
「秘密鍵」「CSR」「サーバー証明書」「CA証明書」など、いろんな言葉が出てきて混乱しがちです。

そこで今回は、登場人物を3人に置き換えて TLS/SSL の仕組み を整理してみます。

👥 登場人物

  • SABURO（サーバー）
    ログを受信する側。自分の正体を証明する必要がある。

  • TAROU（CA：認証局）
    ハンコ屋さん。SABURO が本物かどうかを保証する人。

  • HIROSHI（クライアント）
    ログを送信する側。サーバーが本物かどうか確認したい人。

🔑 手順の流れ

  1. サーバー（SABURO）が秘密鍵を作る
    自分専用のカギ。絶対に誰にも渡さない。

  2. サーバー（SABURO）が申請書（CSR）を作る
    「僕は SABURO サーバーです。この公開鍵で証明書をください」という履歴書みたいなもの。

  3. CA（TAROU）がCSRを受け取って、サーバー証明書を発行する
    「確かにこの人は SABURO です」とハンコを押す。
    出来上がるのが サーバー証明書 (server.crt)。

  4. CA（TAROU）が自分自身の証明書（ca.crt）を作る
    「これが私のハンコの印影です。これで署名したものは信じてください」と配る用。
    ※自己署名CAの場合は、CA証明書も自分で作成する。

  5. サーバー（SABURO）は server.key と server.crt を持つ
    これで「本物のサーバー」として名乗れる。

  6. クライアント（HIROSHI）は事前に ca.crt を受け取る
    この「ハンコ見本」がないと、サーバー証明書が本物か判定できない。

  7. 通信のとき

    • SABURO（サーバー）は HIROSHI（クライアント）にサーバー証明書を提示する
    • HIROSHI はサーバー証明書のハンコと、手元の ca.crt を照合する
    • 一致すれば「SABURO は本物のサーバーだ！」と信じられる

🏭 自己署名CAと実運用の違い

自己署名CA（検証環境）

  • TAROU（CA）も自分でやる
  • ca.crt を自分で作ってクライアントに手動配布する

実運用（本番環境）

  • TAROU（CA）は有名な認証局（DigiCert, GlobalSign, Let’s Encrypt など）
  • ca.crt は最初から OS やブラウザに登録済み
  • 管理者は CSR を送ってサーバー証明書を発行してもらうだけ

✅ まとめ

  • 登場人物を サーバー（SABURO）、CA（TAROU）、クライアント（HIROSHI） で整理すると TLS の仕組みが理解しやすい
  • クライアントは CSR を直接見ない。見るのは サーバー証明書
  • ca.crt は「CAのハンコ見本」。これがないとサーバーの証明書が本物か確認できない
  • 検証用ならオレオレCAを作って配布、本番では信頼されたCAを使う

Discussion