TLS 証明書

サインインに有効な証明書が必要な理由

OpenLM Platform のサインインは、有効で信頼された証明書がある場合にのみ機能します。これは、OpenLM Platform のサービス自体も、その Web アドレスのクライアントである ためです。ほとんどの Web サイトでは、証明書はブラウザーとの接続を保護するだけです。OpenLM Platform では、それ以上の役割を担います。

ユーザーが画面を開くと、要求にはサインイントークンが含まれます。要求を受け取ったサービスは、ブラウザーが使用したのと同じパブリックアドレス https://<DOMAIN>/identity を呼び出してトークンを確認します。この呼び出しは Pod からの通常の HTTPS 接続であり、Pod はブラウザーと同じ方法で証明書を確認します。

 browser ──https──► ingress ──► service ──https──► ingress ──► identity
                     ▲                              ▲
                certificate                    same certificate,
              checked by the browser         checked by the service

そのため、証明書は ブラウザーと Pod の両方にとって 有効である必要があります。

証明書が次の場合	ブラウザー	Pod	結果
パブリック CA 発行、DOMAIN 用、有効期限内	信頼する	信頼する	動作する
自己署名、またはプライベート CA 発行でルートが提供されていない	警告ページ	拒否する	ホームページは読み込まれるが、その後すべての画面が失敗する
別の名前用、または有効期限切れ	警告ページ	拒否する	同上
プライベート CA 発行、ルートを含む完全なチェーンが提供されている	信頼する（ユーザーのマシンにルートがある場合）	信頼する	動作する

ブラウザーを使う人とは異なり、サービスは証明書の警告を無視できません。証明書に問題があると、すべてのユーザーのサインインが失敗します。

証明書を選択する

次のいずれかの証明書の入手元を選びます。

• 推奨: パブリック CA の証明書: たとえば DigiCert、Sectigo、Let's Encrypt の、DOMAIN そのもの、またはそれを含むワイルドカードの証明書です。Pod はパブリック CA を既定で信頼するため、追加の作業はありません。
• これも可: 自社のプライベート CA: ユーザーのマシンは通常、すでにこの CA を信頼しています。Pod は信頼していないため、Pod にプライベート CA を信頼させる の説明に従って、Pod に CA を渡します。
• 不適切: 自己署名証明書: 短期間だけ使用するテストシステムでのみ使用し、自己署名証明書をそれ自体のルートとして扱って、Pod にプライベート CA を信頼させる の手順に従います。

証明書ファイルを準備する

シークレット openlm-lb-cert は、ステップ 3.3 で 2 つのファイルから作成します。

• 証明書ファイル（fullchain.pem）: PEM 形式で、DOMAIN のサーバー証明書、各中間証明書の順に格納し、プライベート CA の場合のみ、最後にルート証明書を格納します。
• 鍵ファイル（privkey.pem）: PEM 形式で、パスワード保護なし。

使用する前にファイルを確認します。

openssl crl2pkcs7 -nocrl -certfile "$TLS_CERT_FILE" | openssl pkcs7 -print_certs -noout | grep subject
openssl x509 -in "$TLS_CERT_FILE" -noout -subject -ext subjectAltName -enddate

2 つのコマンドの出力は、次のように読み取ります。

• 1 つ目のコマンドは、ファイル内のすべての証明書をサーバー証明書から順に一覧表示します。
• 2 つ目のコマンドでは、Subject Alternative Name に DOMAIN が表示され、notAfter の日付が将来である必要があります。

Pod にプライベート CA を信頼させる

Pod は、パブリック CA を信頼する標準的な Linux ベースイメージで実行されます。プライベート CA の場合は、ルート証明書も必要です。チャートは、各サービスに CA バンドルをマウントできます（各コンポーネントの deploymentCerts）。正確な設定はリリースによって異なり、OpenLM がリリースと一緒に提供します。これらの設定がまだ手元にない場合は、パブリック CA の証明書を使用してください。パブリック CA の証明書であれば、これらの設定なしで動作します。

ルートを含める

プライベート CA で最もよくある間違いは、証明書ファイルにサーバー証明書と中間証明書は含まれているものの、ルート が含まれていないことです。社内のマシンのブラウザーは（ルートを持っているため）動作するので、すべて問題ないように見えますが、サービスは SSL エラーまたは IdentityUnavailable エラーで失敗します。ファイルの末尾にルートを追加し、シークレットを作成し直してください。

証明書を更新する

証明書を更新するには、シークレットを置き換え、Ingress コントローラーが変更を自動的に取り込まない場合はコントローラーを再起動します。証明書には有効期限があり、期限が切れるとサインインが機能しなくなります。シークレットを置き換えます。

kubectl -n openlm create secret tls openlm-lb-cert --cert=fullchain.pem --key=privkey.pem \
  --dry-run=client -o yaml | kubectl -n openlm apply -f -

有効期限の日付をカレンダーに登録するか、cert-manager に更新を任せます。シークレット openlm-lb-cert に書き込む cert-manager の Certificate は、プラットフォームを変更せずにそのまま使用できます。

OpenShift の場合

OpenShift ルーターはルートを終端し、ルートが証明書を持っていない場合は自身の証明書を使用します。Red Hat OpenShift: 証明書 を参照してください。