TL;DR

OSSM 2→3 アップグレード後、自己署名証明書を使うサービスへのアクセスが 503 になる。
Ingress Gateway がサーバー証明書の検証に失敗することが原因で、
Istio 1.21 で有効化された以下の2つのデフォルト変更が重なって顕在化する。

フラグ	変更内容	影響
`VERIFY_CERT_AT_CLIENT=true`	Envoy がサーバー証明書を OS の CA バンドルで検証するようになった	自己署名 CA は CA バンドルにないため検証失敗 → 503
`ENABLE_AUTO_SNI=true`	Host ヘッダーから SNI を自動設定するようになった	Ingress Gateway 経由では外部ホスト名が SNI になり、内部 DNS 名の SAN と不一致 → TLS 失敗

暫定対応: DestinationRule に insecureSkipVerify: true
恒久対応: sni で SAN を明示、credentialName で CA を登録、EKU と CA トラストチェーンを整備

これらの破壊的変更は Red Hat の移行ガイドに記載されていない。

この問題が発生する条件

以下をすべて満たす場合に発生する。

条件	詳細
OSSM 2.x → 3.x へアップグレード済み	Istio 1.20 → 1.24 相当
サービスが自己署名証明書を使用	OpenShift 自動生成証明書（Service Serving Certificates）も該当
DestinationRule に `SIMPLE` を設定	Ingress Gateway からの TLS 通信を意図している
Ingress Gateway 経由でアクセス	クラスター外部からルーティングしている

環境構成

DR-1：外部アクセス経路（今回問題が発生した経路）

ブラウザ
│ HTTPS（OpenShift の Route 証明書）
▼
OpenShift Route
│ HTTP（Route が TLS を終端）
▼
Ingress Gateway Pod（Envoy）
│ TLS（tls.mode: SIMPLE）
▼
対象サービス Pod
├─ Envoy サイドカー（TLS 終端・サービスメッシュ制御）
└─ アプリケーションコンテナ（Envoy から plaintext で受信）

DR-2：内部サービス間通信経路（今回影響なし）

内部クライアントサービス Pod
├─ アプリケーションコンテナ（Envoy へ plaintext で送信）
└─ Envoy サイドカー（mTLS・Istio 管理証明書）
│ mTLS（tls.mode: ISTIO_MUTUAL）
▼
対象サービス Pod
├─ Envoy サイドカー（mTLS 終端・サービスメッシュ制御）
└─ アプリケーションコンテナ（Envoy から plaintext で受信）

項目	内容
Service Mesh	OSSM 2.x → 3.x へアップグレード
サイドカー注入	対象 Namespace に `istio-injection=enabled` 済み
DestinationRule	2つ存在。Ingress Gateway→サービス用は `tls.mode: SIMPLE`
	内部クライアントサービス→サービス用は `tls.mode: ISTIO_MUTUAL`（後者は今回影響なし）
PeerAuthentication	存在しない（デフォルト動作）
サービスの証明書	自己署名証明書（OpenShift 自動生成を含む）

症状

ブラウザからサービスにアクセスすると 503 Service Unavailable
Ingress Gateway のログに certificate_verify_failed エラー

前提知識：キーワードの解説

サイドカー（Sidecar）

Podの中にアプリケーションコンテナとは別に自動注入されるプロキシコンテナ（Envoy）のこと。
アプリが意識しなくても、すべての通信がこのプロキシを経由することで
メッシュの機能（暗号化、トラフィック制御など）が実現される。

┌─── 対象サービス Pod ──────────────────────┐
│  [Envoyサイドカー] ← → [サービスコンテナ]  │
└───────────────────────────────────────────┘
         ↑
   メッシュ内の通信はここを通る

Ingress Gateway

メッシュへの「入り口」となる専用のプロキシPod。クラスター外部（ブラウザ）からの通信を受け取り、メッシュ内のサービスに転送する役割を持つ。

DestinationRule

メッシュ内で特定の送信先への通信をどう扱うかを定義するリソース。
今回は tls.mode: SIMPLE が設定されており、
「この送信先との通信にはIstio管理のTLSを使う」という意味になる。

PeerAuthentication

メッシュ内で受信側がどの通信を受け付けるかを定義するリソース。
今回は存在しないため、デフォルト動作が適用されている。

根本原因

OSSM 3 は Istio 1.24 ベース、OSSM 2.6 は Istio 1.20 ベースであり、
この間の Istio 1.21 で以下の2つのデフォルト値が変更された。

① VERIFY_CERT_AT_CLIENT=true

Envoy クライアント側がサーバー証明書を OS の CA バンドルで検証するようになった。

OSSM 2（Istio 1.20）：検証なし → 自己署名証明書でも通信可能
OSSM 3（Istio 1.24）：検証あり → 自己署名 CA は OS の CA バンドルにないため検証失敗

② ENABLE_AUTO_SNI=true（Ingress Gateway 経由では自動解決できないケースがある）

DestinationRule に SNI を明示しなくても Host ヘッダーから自動設定されるようになった。
ただし Ingress Gateway 経由の場合、Host ヘッダーは外部公開ホスト名になる。
一方、自動生成証明書の SAN は <service>.<namespace>.svc.cluster.local 形式の
内部 DNS 名であるため、SNI と SAN が不一致となり TLS ハンドシェイクが失敗する。

OSSM 2 では①②ともオフだったため動作していた問題が、OSSM 3 で一度に顕在化する。

原因の特定

通信経路を整理すると問題の発生箇所が絞り込める。

ブラウザ
  │ HTTPS（OpenShift の Route 証明書）
  ▼
OpenShift Route
  │ HTTP（Route が TLS を終端）
  ▼
Ingress Gateway Pod（Envoy）
  │ TLS（tls.mode: SIMPLE）
  │   ├─ 対象サービスの Envoy サイドカーがサーバー証明書（serving-cert）を提示
  │   └─ Ingress Gateway の Envoy がその証明書を検証  ← ★ VERIFY_CERT_AT_CLIENT=true により失敗
  ▼
対象サービス Pod
  ├─ Envoy サイドカー（TLS 終端・サービスメッシュ制御）
  └─ アプリケーションコンテナ（Envoy から plaintext で受信）

Ingress Gateway → 対象サービス間の DestinationRule に tls.mode: SIMPLE が設定されているため、
Ingress Gateway は TLS で対象サービスに接続しに行く。
OSSM 3（Istio 1.21 以降）では VERIFY_CERT_AT_CLIENT=true がデフォルトになったことで、
このとき Ingress Gateway 側がサーバー証明書を検証するようになった。

certificate_verify_failed：Ingress Gateway でサーバー証明書の検証に失敗
503：その結果、upstream への接続そのものが失敗

「Pod に届いていない」のではなく「TLS ハンドシェイクで弾かれている」。

補足：2つの DestinationRule で挙動が異なった理由

本環境では対象サービスに対して DestinationRule が2つ存在した。

DR	経路	tls.mode	今回の影響
DR-1	Ingress Gateway → 対象サービス	`SIMPLE`	影響あり（503）
DR-2	内部クライアントサービス → 対象サービス	`ISTIO_MUTUAL`	影響なし

DR-2 が影響を受けなかった理由は、ISTIO_MUTUAL では Istio が自動管理する証明書（SPIFFE 形式）を使用するため、対象サービスの serving-cert（OpenShift 内部 CA 署名）が TLS ハンドシェイクに関与しないからである。VERIFY_CERT_AT_CLIENT の検証対象はサーバー証明書であり、Istio 管理証明書は Istio の内部 CA で署名されているため検証を通過する。

一方 DR-1 の SIMPLE では、対象サービスが提示するサーバー証明書（serving-cert）をそのまま Envoy が検証しに行くため、OpenShift 内部 CA が OS の CA バンドルに含まれていないことが問題として顕在化した。

解決策

暫定対処：`insecureSkipVerify: true`

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: example-service
  namespace: <your-namespace>
spec:
  host: <service-host>
  trafficPolicy:
    tls:
      mode: SIMPLE
      insecureSkipVerify: true   # 証明書検証をスキップ

503 は即座に解消されるが、証明書の正当性を確認しない状態になる。
MitM 攻撃への耐性がなくなるため、本番環境では恒久対処に移行すること。

恒久対処：`sni` と `credentialName` を明示する

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: example-service
  namespace: <your-namespace>
spec:
  host: <service-host>
  trafficPolicy:
    tls:
      mode: SIMPLE
      sni: <service>.<namespace>.svc.cluster.local   # 証明書の SAN と一致させる
      credentialName: my-ca-cert                     # CA 証明書を Secret で参照

フィールド	目的	対応する原因
`sni`	SNI を証明書の SAN（内部 DNS 名）に合わせる	ENABLE_AUTO_SNI の自動解決の限界
`credentialName`	自己署名 CA を明示して検証を通す	VERIFY_CERT_AT_CLIENT=true

credentialName で参照する Secret は以下のように用意する（Istio 1.14+）。

oc create secret generic my-ca-cert \
  --from-file=ca.crt=./ca.crt \
  -n <your-namespace>

証明書の EKU とトラストチェーンの確認

insecureSkipVerify を外した後も503が続く場合は、証明書自体の問題が残っている。

openssl x509 -in server.crt -noout -text | grep -A3 "Extended Key Usage"

serverAuth と clientAuth の両方が含まれていること、
および CA トラストチェーンが正しく構成されていることを確認する。

まとめ

フェーズ	内容
症状	503 + `certificate_verify_failed`
問題の発生箇所	Ingress Gateway によるサーバー証明書の検証失敗
根本原因①	`VERIFY_CERT_AT_CLIENT=true`：自己署名 CA が OS の CA バンドルにない
根本原因②	`ENABLE_AUTO_SNI` の限界：Ingress Gateway 経由で SNI と SAN が不一致
暫定対処	`insecureSkipVerify: true` で検証をスキップ
恒久対処	`sni` で SAN 一致、`credentialName` で CA を明示、EKU・トラストチェーンを整備

OSSM 2→3 のアップグレードでは TLS 周りのデフォルト動作が複数変わっている。
自己署名証明書（自動生成含む）を使うサービスが Service Mesh に参加している場合は、
アップグレード前にこの点を必ず確認してほしい。

今後の教訓

トラブルシューティングの進め方

今回の対応を振り返ると、エラーログは早期に取得できていたが、
「ログが何を示しているか」の読み取りと「構成の把握」が不足していたため、
原因特定に時間がかかった。

以下のループを意識することで、次回以降の解決速度が上がる。

通信経路を図示する
  │
  ▼
ログからどのレイヤーで失敗しているか読み取る
  │
  ▼
仮説を1つ立てる
  │
  ▼
検証する
  │
  ▼
結果で仮説を修正 → 次の仮説へ

やみくもに設定を変えて試すのではなく、仮説を立ててから検証することが遠回りを防ぐ。

ログの読み取り方

エラーメッセージはレイヤーを教えてくれる。

エラー	意味	該当レイヤー
`no healthy upstream` / `connection refused`	TCP 接続失敗	Pod に届いていない
`certificate_verify_failed`	TLS ハンドシェイク失敗	Pod には届いている

Ingress Gateway の Envoy ログが最も情報量が多いが、権限上確認できない場合でも
対象サービス側の Envoy サイドカーログや Kiali から同等の切り分けが可能。

平時にやっておくこと

自分のシステムの通信経路を図示して説明できる状態にしておく
DestinationRule 等のメッシュ設定が何のために存在するか把握しておく

構成知識は障害時に初めて理解しようとすると間に合わない。
平時のドキュメント整備が障害時の自己解決率を上げる最短ルートになる。

参考リンク