未採用 Base64 編碼的憑證：
Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded
格式不正確或經過 Base64 編碼但內容有誤的憑證：
Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)
格式不正確或經過 Base64 編碼但內容有誤的憑證：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.
解決方案
你可以透過下列任一方式解決問題：
您在 ClientConfig 中提供的憑證值應為 Base64 編碼字串和 PEM 格式字串。詳情請參閱「編碼 CA 憑證」。
憑證鏈結不完整或與伺服器不符：
SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate
憑證鏈結不完整 (對應至無效的部分鏈結，該鏈結並非從根開始或不連續)：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
憑證鏈結有效，但不符合 OIDC 伺服器：
AIS was expecting the server to have a different certificate
憑證鏈結有效，但不符合 OIDC 伺服器：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
解決方案
您在 ClientConfig 中提供的憑證值必須包含格式正確的憑證鏈結，且與身分識別提供者相符。
如要進一步瞭解如何格式化及編碼憑證，請參閱「編碼 CA 憑證」。
在 Windows 機器上使用 gcloud anthos auth login 指令搭配 OIDC，為叢集存取權產生 kubeconfig 檔案時，kubectl 指令可能會失敗，並顯示以下錯誤訊息：The command line is too long.
這個問題只會發生在 Windows 系統上，使用相同 kubeconfig 檔案的 Linux 機器則不受影響。根本原因與 Azure Active Directory (Azure AD) 產生驗證權杖的大小有關，當使用者屬於大量群組時 (約 70 到 200 個群組，視群組名稱長度而定)，就會發生這個問題。
這個大型權杖會導致 kubectl 指令執行失敗，因為權杖長度超過 Windows 允許的指令列長度上限 (8,191 個字元)。
錯誤訊息
$ kubectl --kubeconfig test-kubeconfig.yml get nodes
The command line is too long.
The command line is too long.
E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-31 (世界標準時間)。"],[],[],null,["# Troubleshoot OIDC provider issues\n=================================\n\nThis document provides troubleshooting guidance for OIDC and AzureAD identity provider issues\nin GKE Identity Service.\n\nIncorrect formatting of certificate\n-----------------------------------\n\nThis issue occurs when the certificate value has formatting errors. Formatting\nissues can correspond to certificate values that aren't base64 encoded and values\nthat are base64 encoded but incorrect. The issue can also arise if the certificate\nisn't signed by a root certificate authority or a correctly formatted trust chain isn't provided.\n\n### Error messages\n\nThe following examples are of error messages for scenarios where the certificate format is incorrect:\n\n- Certificate that is not base64 encoded:\n `Failed creating HTTP client to fetch the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: Unable to decode data field, the value should be Base64 encoded`\n\n- Certificate that is not formatted correctly or is base64 encoded but incorrect:\n `Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)`\n\n- Certificate that is not formatted correctly or is base64 encoded but incorrect:\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: Unable to load TLS certificates.`\n\n### Solution\n\nYou can resolve the issues in one of the following ways:\n\n- The certificate value you provide in the ClientConfig should be a base64 encoded string and PEM formatted string. For more information, see [Encode CA certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#encodecertificate).\n- If your provider doesn't use certificates signed by a root certificate authority, then you need to configure GKE Identity Service with a certificate trust chain. For more information, see [Intermediate certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#intermediatecertificates).\n\nWrong certificate value\n-----------------------\n\nThis issue occurs when the certificate has a mismatched value. In this case, the formatting of the certificates is correct, however they don't match the server. It can also indicate that there were no certificates in the configuration.\n\nA certificate value can be considered incorrect in any of the following scenarios:\n\n- An incorrect certificate value is shared in the ClientConfig. A certificate value is incorrect when the `issuer` of the server certificate does not match the `subject` of the configured certificate.\n- The certificate in the ClientConfig isn't a base64 encoded string.\n- The certificate chain is not provided when intermediate certificates are used to issue the server certificate.\n\n### Error message\n\nThe following examples are of error messages for scenarios where there's a mismatch in the certificate value:\n\n- Certificate chain is not complete or does not match the server:\n `SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate`\n\n- Certificate chain is not complete (corresponds to an invalid partial chain which doesn't start at the root or isn't contiguous):\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: The server's TLS certificate did not match expectations.`\n\n- Certificate chain is valid but doesn't match the OIDC server:\n `AIS was expecting the server to have a different certificate`\n\n- Certificate chain is valid but doesn't match the OIDC server:\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: The server's TLS certificate did not match expectations.`\n\n### Solution\n\nThe certificate value you provide in the ClientConfig needs to include a correctly formatted certificate chain that matches the identity provider.\nFor more information on how to format and encode certificates, see [Encode CA certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#encodecertificate).\n\n`kubectl` commands fail when using a kubeconfig file generated by the `gcloud anthos auth login` command\n--------------------------------------------------------------------------------------------------------\n\nWhen you use the `gcloud anthos auth login` command with OIDC on Windows machines to generate a kubeconfig file for cluster access, `kubectl` commands might fail with the following error message: **`The command line is too long.`**\nThis issue occurs specifically on Windows systems and does not affect Linux machines that use the same kubeconfig file. The underlying cause is related to the size of the authentication token that's generated by Azure Active Directory (Azure AD) when a user belongs to a large number of groups (approximately 70 to 200 groups, depending on the lengths of group names).\n\nThis large token causes the execution of `kubectl` commands to fail because it exceeds the maximum length of the command line that's allowed by Windows, which is *8,191* characters.\n\n### Error message\n\n```\n$ kubectl --kubeconfig test-kubeconfig.yml get nodes\n\nThe command line is too long.\nThe command line is too long.\nE0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get \"https://10.35.0.86:443/api?timeout=32s\": getting credentials: exec: executable gcloud failed with exit code 1\nThe command line is too long.\nE0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get \"https://10.35.0.86:443/api?timeout=32s\": getting credentials: exec: executable gcloud failed with exit code 1\nThe command line is too long.\nE0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get \"https://10.35.0.86:443/api?timeout=32s\": getting credentials: exec: executable gcloud failed with exit code 1\nUnable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1\n```\n\n### Solution\n\nTo resolve this issue, do the following:\n\n- **Upgrade to GKE cluster version 1.28 or later**\n\n If you're running a version of GKE cluster that is earlier than 1.28, we recommend that you upgrade to the supported version.\n- **Reduce the affected user's group memberships**\n\n Reducing the number of groups the authenticating user belongs to below the problematic threshold (approximately 70 groups) can resolve the issue.\n- **Increase the affected user's group memberships**\n\n The [Microsoft Entra ID feature has a limit](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) for the number of groups emitted in a token. Having between 70 to 200 group memberships might cause authentication problems. However, you can resolve the identity provider issues by increasing the number of group memberships beyond this limit. Due to the behavior of this limit, Azure AD omits groups from the `id_token` when the number of memberships becomes excessively large, preventing the command line from becoming too long and so resolving the identity provider issues. Review the [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) to confirm the limit and for more details."]]
