这个篇文章的目的其实也就是对我之前的一些学习材料做一个总结。故事是这样的，之前的工作需要进行 Onboard 一个服务，该服务是基于 MTLS 的验证方式，由于我们也是第一次做这样的事情，对面的自信也让我们错误的估计了该任务的复杂度，所以踩了很多坑，这样也总结下。。。
什么是 MTLS 验证
众所周知，TLS 是一种基于证书的验证方式，通过非对阵加密的算法，以及权威 CA 的方式，可以让服务信任一些系统。HTTPS 协议也是基于 TLS 来作为安全的保障。相比较于 TLS，MTLS 需要客户端也发送其自身的证书来让服务器验证客户端的合法性。具体的表现可以参考下图：
另外，早 OAUTH 2.0 里面也对 MTLS 相关的安全性提出了建议：rfc 8705 提案。至此，我们可以假定完成了对 MTLS 的了解。
如何申请证书
说到申请证书，我看到很多的博客已经直接上手前往第三方的 CA 平台进行申请。但这其实也有很多的门道，证书是否有效，如何申请证书，这些问题统统需要和 Partner Team 进行沟通。简单的说，一个证书所具有的属性无外乎有以下几个：
- 有效时间 (expriy time)
- 证书指纹 (thumbprint)
- 名字 (Common Name)
- 签发者 & 证书链 (Issuer & Cert Chain)
在 Onboard 之前，我们需要和对方的 Team 沟通好，是否有这些要求。在实际过程中，我们踩过这样的坑，对方除了对 Common Name 有要求之外，也对签发者 & 证书链有要求，但是当时我们并没有求证，最后导致申请的证书无法使用。
有效时间，这一点保证了证书是否过期，单独拿出来讲是因为苹果今年提出了证书只能支持 1年的有效时间，如果有效期超过了一年，那么在某些客户端中，也将会认为该证书失效。
Common Name 指的是证书的 Subject Name，通常可以看作为证书的名字，这一点也可以和证书指纹同时使用，用来唯一标识一个证书。不过和 Thumprint 不同是，在更新证书的时候，Common Name 不需要再次和 Partner Team 进行沟通，新证书只要和原有证书同名即可使用，而 Thumbprint 则需要再次更新。
签发者和证书链则是可以保证证书是被可信方签发，防止黑客使用其他签发者签发的证书访问资源。通常来说，如果对于企业内部的系统，会有一个内部的签发机构，大家都会基于这个签发机构进行申请，从而保证数据的安全。
知道了以上的信息，我们就可以针对不同的要求，寻找对应的证书签发机构了。
如何部署证书
完成了证书的申请，就到了部署。一般而言，证书都是需要进行安装到本地，也就是发送请求的服务器或者终端上。申请完证书之后，一般会有两个文件，对应着私钥和公钥。对于服务器而言，可以按照 Apache 或者 Nginx 对应的要求进行安装即可。这里主要是含有私心的推荐一下 Azure Key Vault。其主要的一个逻辑图如下：
Key Vault 的原理就是，应用程序只负责申请 Reponse，然后交给 Application Gateway，由其来进行 Reponse 的签署。这样也就保证了通信的安全性。
使用 Azure Key Vault 的好处有很多，比如：
- 更高的安全性，因为 TLS/SSL 证书不直接由应用程序开发团队处理。 集成允许独立的安全团队执行以下操作：
- 设置应用程序网关。
- 控制应用程序网关生命周期。
- 授权选定的应用程序网关访问存储在密钥保管库中的证书。
- 支持将现有证书导入密钥保管库中。 或者使用 Key Vault API 与任何受信任的 Key Vault 合作伙伴一起创建并管理新证书。
- 支持自动续订存储在密钥保管库中的证书。
其大概的一个流程如下：
如何发送 MTLS 请求
这个问题再次不加赘述，因为对于不同的语言来说其使用手册上都会进行描述，这里主要说一下几点 Best Practise。
- 不要在请求中人为的指定 TLS 版本 & 加密算法，而是让服务器和客户端自己协商而定。这样的好处是，当旧算法被证明不安全之后，我们依旧可以不需要修改客户端代码而保证通信的安全。
- 尽可能使用最新的版本。这里也是考虑到最新的算法的安全性更加。比如之前遇到的 OpenSSH 的巨大漏洞。
做到了以上几点，应该就可以很顺利的 Onboard 到一个 MTLS Service 上了。不过具体实践中应该还会遇到各种各样的问题，我们当时进行 Onboard 的时候，对方拍着胸脯说一天搞定，结果花了我们两周时间才最后定稿，也算是吸取了教训了。