https://ibm-developer.connpass.com/event/370019/
セッション内容
証明書ってなに？
SSL は脆弱性が見つかったため、今は TLS1.2, 1.3 が利用されています。
TLS プロトコルによって、通信を暗号化し盗聴や改ざんを防いでいます。
プロトコル であるため、実装自体は TLS ソフトウェア毎に異なります。
共通鍵でハッシュ値を作り、クライアント・サーバ間で改ざんされていないか調べます。
証明書が「該当サーバの公開鍵」を持っており、それをクライアントに送ります。
エンジニアが簡易的に利用するのは Let’s Encrypt ですね。
Private CA とあるように、社内用に自分たちで CA をホストできるのですね。
とある会社 X があったときに、 X 社のインフラ・システム担当者が証明書を取る、という図ですね。 たしかに、誰かが代表して X 社用の公開鍵作成の作業を行っていますものね..。
証明書の有効期限がどんどん短くなっていくようです。 Apple が提案し、それが採択されました。
証明書の発行手順について見ていきます。
証明書には公開鍵が含まれます。 その対になるのが秘密鍵です。
X 社のインフラ担当者は公開鍵と秘密鍵のペアを作成し、秘密鍵は厳重に管理します。
CSR という要求ファイルを作成します。 これには必要なドメイン名や公開鍵の情報、署名方法などを記録したファイルです。 「証明書要求ファイル」を秘密鍵でハッシュ化しそれを CSR に含めることで、CA 側で本当に正しい秘密鍵か？がわかります。
上記要求ファイルを Base64 エンコードし、それを CA 認証局ブラウザで提出します。
d. 申請情報の入力では、 CSR に含まれない必要事項を記載します。 CSR は最小限の情報しか含んでいないためです。
CA 認証局 側はドメインが本当に正しいか？をチェックします。これを DCV と呼びます。
OV/EV の場合のみ、本当にその組織が存在するか？申請者が存在しているか？を確認し、ニセの組織でないかチェックします。
CA が「X 社の証明書」 を署名します。 これは CA 自身で作成した CA 秘密鍵で署名 します。 TODO: ここに CA 秘密鍵で署名する意味を書く
水色の領域が X 社の社内環境です。
社内のサーバ同士では Private 用の証明書を発行して通信することが多いらしいです。 ゼロトラストの実現のために、社内用に証明書を発行しているのですね。
クライアント（社外）との通信については、ちゃんとした CA に署名された証明書を利用しています。
自動化ソリューション
手動でやっていることが多く、ヒューマンエラーの可能性が非常に高いのが m ン台です。 証明書管理をエクセルやスプシでやるのも辛いです。
そのため、これからどうするか？どうすれば自動化できるか？について (IBM 社が) 考えます。
