问题描述
在先前的四篇博文
1：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案三)
2：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案二)
3：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案一)
4：【Azure APIM】如何解决后端API服务配置自签名证书时APIM请求报错500：Error occured while calling backend service
5：【Azure 环境】在Windows环境中使用OpenSSL生成自签名证书链步骤分享
我们分别介绍了使用OpenSSL生成自签名证书，然后解决APIM服务对自签名证书的信任问题。不论是APIM托管的网关，还是自建的网关都可以通过安装证书后使得请求受信任，通过配置API跳过证书验证环节。
在方案三中，开始从自建网关本身AKS POD”方面入手，通过配置 SSL_CERT_FILE 环境变量，来安装自签名证书 （根证书和中间证书）到POD中解决问题。
除了以上三种方案的情况下：在AKS集群的官方文档中，说可以直接更新集群，把自定义证书颁发机构（CA）向节点的信任存储添加多达 10 个 base64 编码的证书。
所以，基于这个文档，本文尝试了第四种方案：使用 az aks update --custom-ca-trust-certificates 证书命令
方案步骤
准备步骤：准备好中间证书和根证书合并一起的 .crt 内容
导出方法：通过浏览器导出中间证书+根证书的 crt 文件，其内容是 Base64 编码
第一步：把准备好的证书传递到AKS集群
因aks集群已经创建好，所以使用 az aks update 指令
az aks update \ --resource-group <resource-group-name> \ --name <cluster-name> \ --custom-ca-trust-certificates <path-to-certificate-file>
执行截图
第二步：验证自签名CA证书是否在节点中正常工作
1：使用 kubectl get nodes ，列出节点名称
2：进入节点debug模式：使用 kubectl debug node/<节点名> -it --image=mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11， 如：kubectl debug node/aks-agentpool-20066971-vmss00000j -it --image=mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
3：使用 chroot /host 命令，把操作目录从当前容器环境 切换到 节点操作环境
4：对比访问两个不同自签名CA证书的URL
操作结果截图：
第三步：访问APIM的自建网关请求，自签名证书依旧不被信任。
为什么呢？把自签名的根证书，中间证书都安装到AKS集群中了，为何使用debug模式就可以信任这个自签名证书，而 APIM Self-hosted gateway pod却不可以呢？
疑问解答
Debug pod 之所以能信任，是因为它用的是通用 Ubuntu 基础镜像，走的是系统 CA bundle；
APIM Self‑hosted Gateway 用的是微软封装的网关容器 + .NET TLS 验证路径，完全不看 node 的 CA。
这一点在 AKS 官方文档中是明确写清楚的：“Certificates added to the AKS node trust store aren’t available to containers running in pods.”
AKS Node 安装 CA，只对 Node 生效，对 Pod 无效。 这一点，在文章开头的官方文档截图中，也特别提醒。只是，最开始没有正确理解这句话的意义！
所以，如果要解决APIM 中自签名CA证书的信任问题。目前验证下来，只有三种方式：
1：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案一)
2：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案二)
3：【Azure APIM】APIM的自建网关如何解决自签名证书的受信任问题呢？(方案三)
[完]
参考资料
在 Azure Kubernetes 服务（AKS）中使用自定义证书颁发机构（CA） ：https://docs.azure.cn/zh-cn/aks/custom-certificate-authority
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
