--- title: TLS 証明書 description: サインインを機能させるために OpenLM Platform が有効で信頼された証明書を必要とする理由、証明書の選び方、プライベート CA の使用方法について説明します。 product: OpenLM Platform --- ## サインインに有効な証明書が必要な理由 OpenLM Platform のサインインは、有効で信頼された証明書がある場合にのみ機能します。これは、**OpenLM Platform のサービス自体も、その Web アドレスのクライアントである** ためです。ほとんどの Web サイトでは、証明書はブラウザーとの接続を保護するだけです。OpenLM Platform では、それ以上の役割を担います。 ユーザーが画面を開くと、要求にはサインイントークンが含まれます。要求を受け取ったサービスは、ブラウザーが使用したのと同じパブリックアドレス `https:///identity` を呼び出してトークンを確認します。この呼び出しは Pod からの通常の HTTPS 接続であり、Pod はブラウザーと同じ方法で証明書を確認します。 ```text 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 を渡します。 - **不適切: 自己署名証明書**: 短期間だけ使用するテストシステムでのみ使用し、自己署名証明書をそれ自体のルートとして扱って、[Pod にプライベート CA を信頼させる](#pod-にプライベート-ca-を信頼させる) の手順に従います。 ## 証明書ファイルを準備する シークレット `openlm-lb-cert` は、[ステップ 3.3](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-3-secrets#33-tls-証明書を追加する) で 2 つのファイルから作成します。 - **証明書ファイル**（`fullchain.pem`）: PEM 形式で、`DOMAIN` のサーバー証明書、各中間証明書の順に格納し、**プライベート CA の場合のみ**、最後にルート証明書を格納します。 - **鍵ファイル**（`privkey.pem`）: PEM 形式で、パスワード保護なし。 使用する前にファイルを確認します。 ```bash 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 の証明書であれば、これらの設定なしで動作します。 :::warning[ルートを含める] プライベート CA で最もよくある間違いは、証明書ファイルにサーバー証明書と中間証明書は含まれているものの、**ルート** が含まれていないことです。社内のマシンのブラウザーは（ルートを持っているため）動作するので、すべて問題ないように見えますが、サービスは SSL エラーまたは `IdentityUnavailable` エラーで失敗します。ファイルの末尾にルートを追加し、シークレットを作成し直してください。 ::: ## 証明書を更新する 証明書を更新するには、シークレットを置き換え、Ingress コントローラーが変更を自動的に取り込まない場合はコントローラーを再起動します。証明書には有効期限があり、期限が切れるとサインインが機能しなくなります。シークレットを置き換えます。 ```bash 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: 証明書](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/platforms/openshift#証明書) を参照してください。