https://ibm-developer.connpass.com/event/370019/
セッション内容
証明書ってなに？
SSL は脆弱性が見つかったため、今は TLS1.2, 1.3 が利用されています。
SSL/TLS プロトコルによって、通信を暗号化し盗聴や改ざんが防がれています。
ただし プロトコル であるため、あくまでも実装自体は利用する SSL/TLS クライアントソフトウェア毎に異なります。
改ざんを検知するために、「クライアントが作成した共通鍵」でハッシュ値を作り、共通鍵とハッシュ値のペアをサーバへ送信します。 サーバはサーバ自身でハッシュ値を計算し、本当にハッシュが一致するか？を調べます。
共通鍵とハッシュ値によって、本当にコンテンツが改ざんされていないか？を検証できます。 改ざんされていればハッシュ値の値がずれるためです。
なりすまし対策には、証明書の正当性を利用します。 証明書の署名を CA へ向かってクライアント検証を依頼し、「本当にサーバーの証明書か？正しい公開鍵か？」を確認しています。
CA は認証局のことであり、厳密な審査を受けた特定の認証局のみが公的な署名を行います。 会社内の通信、といったプライベートなものについては公的な認証局ではなく、セルフホストした認証ソフトウェアが使えるようです。
url: https://itguy.hatenablog.jp/entry/2017/10/05/184413
title: "主要商用認証局(CA) - IT Guy"
description: "Certificate Authority 主要CA Issuer（マーケットシェア順 - 2018年時点） IdenTrust Comodo DigiCert : Symantec PKI事業買収. サイバートラストもDigiCertの証明書販売 GoDaddy GlobalSign : GMOグループ Certum Actalis Entrust Secom Let's Encrypt 主要CA Issuer（マーケットシェア順 - 2016年時点） Comodo Symantec : Verisignを買収 GoDaddy GlobalSign DigiCert : Cybertrust…"
host: itguy.hatenablog.jp
favicon: https://itguy.hatenablog.jp/icon/link
image: https://ogimage.blog.st-hatena.com/8599973812302688980/8599973812305083708/1558503800
CA といっても色々と存在し、価格やサポートを考慮して採用するようです。 エンジニアが個人開発でよく利用するのは Let’s Encrypt ですね。
Private CA とあるように、社内用に自分たちで CA をホストできるのですね。
証明書の運用・管理
とある会社 X があったときに、 X 社のインフラ・システム担当者が証明書を取る というケース、として ganyariya はこの図を読むことにしました。
たしかに、X 社用の公開鍵作成の作業をおそらくインフラ・社内インフラの方々が行っていますものね..。
インフラ担当者が CA に CSR を作成して申請し、秘密鍵ならびに証明書を ローカル に保存するようです。
この「秘密鍵」と「証明書」の管理が大変そうです。
- インフラ担当者がいなくなったらどこに保存したのかわからなくなった
- 秘密鍵を置いていたクラウドストレージ・社内サーバから秘密鍵が漏れてしまった
などの問題が起きそうです。
証明書の有効期限がどんどん短くなっていくようです。 Apple が提案し、それが採択されました。
証明書の発行手順について見ていきます。
証明書には公開鍵が含まれます。 その対になるのが秘密鍵です。
X 社のインフラ担当者は公開鍵と秘密鍵のペアを作成し、秘密鍵は厳重に管理します。
CSR という要求ファイルを作成します。 これには必要なドメイン名や公開鍵の情報、署名方法などを記録したファイルです。 「証明書要求ファイル」を秘密鍵でハッシュ化しそれを CSR に含めることで、CA 側で本当に正しい秘密鍵か？がわかります。
上記要求ファイルを Base64 エンコードし、それを CA 認証局ブラウザで提出します。
d. 申請情報の入力では、 CSR に含まれない必要事項を記載します。 CSR は最小限の情報しか含んでいないためです。
CA 認証局 側はドメインが本当に正しいか？をチェックします。これを DCV と呼びます。
OV/EV の場合のみ、本当にその組織が存在するか？申請者が存在しているか？を確認し、ニセの組織でないかチェックします。
CA が「X 社の証明書」 を署名します。 これは CA 自身で作成した CA 秘密鍵で署名 します。
CA 秘密鍵で署名することで、インフラ管理者はそれを CA の公開鍵で検証できます。 検証が成功すれば「本当に正しい CA で署名されている」とわかります。
水色の領域が X 社の社内環境です。
社内のサーバ同士では Private 用の証明書を発行して通信することが多いらしいです。 ゼロトラストの実現のために、社内用に証明書を発行しているのですね。
クライアント（社外）との通信については、ちゃんとした CA に署名された証明書を利用しています。
自動化ソリューション
手動でやっていることが多く、ヒューマンエラーの可能性が非常に高いのが m ン台です。 証明書管理をエクセルやスプシでやるのも辛いです。
そのため、これからどうするか？どうすれば自動化できるか？について (IBM 社が) 考えます。
