[GH-ISSUE #265] [Feature] 支持上传证书 #163

New issue

Closed

opened 2026-03-03 01:01:19 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 01:01:19 +03:00

Owner

Originally created by @SeaEpoch on GitHub (Oct 26, 2024).
Original GitHub issue: https://github.com/certimate-go/certimate/issues/265

功能描述
目前只支持对阿里云的 OSS、CDN 等进行部署，本质上是可以进行所有云产品的部署的。所以，我有个建议可以实现对 Aliyun 的所有云产品进行 SSL 证书部署。

首先是 Aliyun 提供了上传 SSL 证书的 OpenAPI：UploadUserCertificate- 上传证书。通过这个接口就可以将生成的证书上传到 Aliyun 数字证书管理服务平台。

然后是 Aliyun 提供了创建部署任务的 OpenAPI：CreateDeploymentJob- 创建部署任务。其中，这个部署任务是可以对几乎任何 Aliyun 产品进行 SSL 证书部署的。

动机
如果成功实现，该项目将会是史无前例的一次跃进，这将是一个里程碑。我相信会为该项目带来巨大的关注！

为什么这么做？
准确来说对于 Aliyun 虚拟主机等一些云产品既没有 SSH Terminal，也没有本地部署的途径（唯一途径是 FTP 上传文件，但是局限性非常大，几乎不可能上传 SSL 证书）。所以，这类云产品急需 Certimate 的支持！

但是上述的部署任务 OpenAPI 是支持对云虚拟主机进行 SSL 证书部署的。我想这会是一个重要的改进！

Originally created by @SeaEpoch on GitHub (Oct 26, 2024). Original GitHub issue: https://github.com/certimate-go/certimate/issues/265 **功能描述** 目前只支持对阿里云的 OSS、CDN 等进行部署，本质上是可以进行所有云产品的部署的。所以，我有个建议可以实现对 Aliyun 的所有云产品进行 SSL 证书部署。首先是 Aliyun 提供了上传 SSL 证书的 OpenAPI：[UploadUserCertificate- 上传证书](https://next.api.aliyun.com/document/cas/2020-04-07/UploadUserCertificate)。通过这个接口就可以将生成的证书上传到 Aliyun 数字证书管理服务平台。然后是 Aliyun 提供了创建部署任务的 OpenAPI：[CreateDeploymentJob- 创建部署任务](https://next.api.aliyun.com/document/cas/2020-04-07/CreateDeploymentJob)。其中，这个部署任务是可以对几乎任何 Aliyun 产品进行 SSL 证书部署的。 **动机** 如果成功实现，该项目将会是史无前例的一次跃进，这将是一个里程碑。我相信会为该项目带来巨大的关注！ **为什么这么做？** 准确来说对于 **Aliyun 虚拟主机**等一些云产品既没有 SSH Terminal，也没有本地部署的途径（唯一途径是 FTP 上传文件，但是局限性非常大，几乎不可能上传 SSL 证书）。所以，这类云产品急需 Certimate 的支持！但是上述的**部署任务 OpenAPI** 是支持对**云虚拟主机**进行 SSL 证书部署的。我想这会是一个重要的改进！

kerem

2026-03-03 01:01:19 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 01:01:20 +03:00

Author

Owner

@usual2970 commented on GitHub (Oct 26, 2024):

感谢反馈~ 参考 #17

@usual2970 commented on GitHub (Oct 26, 2024): 感谢反馈~ 参考 #17

kerem commented

2026-03-03 01:01:20 +03:00

Author

Owner

@SeaEpoch commented on GitHub (Oct 26, 2024):

感谢反馈~ 参考 #17

并不是，我并没有看到合适的解决方案。我觉得我提出的这个功能更像是 Certd 的部署至阿里云任意云资源功能。换句话说，我希望能够支持对阿里云云虚拟主机的SSL证书部署。因为这个主机不同于其他云服务器产品，相对部署 SSL 更加麻烦。所以自动化解决非常有必要。

@SeaEpoch commented on GitHub (Oct 26, 2024): > 感谢反馈~ 参考 #17 并不是，我并没有看到合适的解决方案。我觉得我提出的这个功能更像是 Certd 的**部署至阿里云任意云资源**功能。换句话说，我希望能够支持对阿里云云虚拟主机的SSL证书部署。因为这个主机不同于其他云服务器产品，相对部署 SSL 更加麻烦。所以自动化解决非常有必要。

kerem commented

2026-03-03 01:01:20 +03:00

Author

Owner

@fudiwei commented on GitHub (Oct 26, 2024):

在实现阿里云相关部署功能的时候有注意到这个接口了，但有三个比较大的问题：

对 SLB 来说不支持 SNI。
部署过程是异步的，这样在 certimate 里无法记录是否真的部署成功。虽然阿里云也提供了查询执行结果的接口，但目前的 certimate 架构来说支持异步任务是一个吃力不讨好的事情。
需要传入云资源 ID（不完全等同于实例 ID），但某些产品的云资源 ID 在 Web 控制台是没有地方显示的（就比如你提到的云虚拟主机），必须要通过它的 ListCloudResources 接口才能获取。但这出现某种“悖论”了 —— 如果用户已经自己能调用接口取得这个云资源 ID 了，那么完全就可以顺手把部署的逻辑也给实现了；如果用户自己没能力拿到这个云资源 ID，那么在 certimate 里就填入不了这个参数，自然也无法调用这个接口。如果说是在 certimate 里提供一个跟阿里云 Web 控制台一样的选择面板来选择云资源，这个工作量就很大，对目前的 certimate 来说优先级不高。

综上原因最后没有采用这个方案。

但这个接口确实有两个非常明显的优势：

允许同时部署多个地域下的实例。
支持混合云。

也许等之后 certimate 足够稳定的情况下，才有足够的动机来基于这个服务来实现阿里云的证书部署能力。

@fudiwei commented on GitHub (Oct 26, 2024): 在实现阿里云相关部署功能的时候有注意到这个接口了，但有三个比较大的问题： - 对 SLB 来说不支持 SNI。 - 部署过程是异步的，这样在 certimate 里无法记录是否真的部署成功。虽然阿里云也提供了查询执行结果的接口，但目前的 certimate 架构来说支持异步任务是一个吃力不讨好的事情。 - 需要传入云资源 ID（不完全等同于实例 ID），但某些产品的云资源 ID 在 Web 控制台是没有地方显示的（就比如你提到的云虚拟主机），必须要通过它的 `ListCloudResources` 接口才能获取。但这出现某种“悖论”了 —— 如果用户已经自己能调用接口取得这个云资源 ID 了，那么完全就可以顺手把部署的逻辑也给实现了；如果用户自己没能力拿到这个云资源 ID，那么在 certimate 里就填入不了这个参数，自然也无法调用这个接口。如果说是在 certimate 里提供一个跟阿里云 Web 控制台一样的选择面板来选择云资源，这个工作量就很大，对目前的 certimate 来说优先级不高。综上原因最后没有采用这个方案。但这个接口确实有两个非常明显的优势： - 允许同时部署多个地域下的实例。 - 支持混合云。也许等之后 certimate 足够稳定的情况下，才有足够的动机来基于这个服务来实现阿里云的证书部署能力。

kerem commented

2026-03-03 01:01:20 +03:00

Author

Owner

@SeaEpoch commented on GitHub (Oct 26, 2024):

在实现阿里云相关部署功能的时候有注意到这个接口了，但有三个比较大的问题：

对 SLB 来说不支持 SNI。

部署过程是异步的，这样在 certimate 里无法记录是否真的部署成功。虽然阿里云也提供了查询执行结果的接口，但目前的 certimate 架构来说支持异步任务是一个吃力不讨好的事情。

需要传入云资源 ID（不完全等同于实例 ID），但某些产品的云资源 ID 在 Web 控制台是没有地方显示的（就比如你提到的云虚拟主机），必须要通过它的 ListCloudResources 接口才能获取。但这出现某种“悖论”了 —— 如果用户已经自己能调用接口取得这个云资源 ID 了，那么完全就可以顺手把部署的逻辑也给实现了；如果用户自己没能力拿到这个云资源 ID，那么在 certimate 里就填入不了这个参数，自然也无法调用这个接口。如果说是在 certimate 里提供一个跟阿里云 Web 控制台一样的选择面板来选择云资源，这个工作量就很大，对目前的 certimate 来说优先级不高。

综上原因最后没有采用这个方案。

但这个接口确实有两个非常明显的优势：

允许同时部署多个地域下的实例。

支持混合云。

也许等之后 certimate 足够稳定的情况下，才有足够的动机来基于这个服务来实现阿里云的证书部署能力。

感谢你的回答，我已经理解了你们的顾虑，你说的确实非常有道理。很期待以后的 certimate，哈哈哈~

@SeaEpoch commented on GitHub (Oct 26, 2024): > 在实现阿里云相关部署功能的时候有注意到这个接口了，但有三个比较大的问题： > > * 对 SLB 来说不支持 SNI。 > * 部署过程是异步的，这样在 certimate 里无法记录是否真的部署成功。虽然阿里云也提供了查询执行结果的接口，但目前的 certimate 架构来说支持异步任务是一个吃力不讨好的事情。 > * 需要传入云资源 ID（不完全等同于实例 ID），但某些产品的云资源 ID 在 Web 控制台是没有地方显示的（就比如你提到的云虚拟主机），必须要通过它的 `ListCloudResources` 接口才能获取。但这出现某种“悖论”了 —— 如果用户已经自己能调用接口取得这个云资源 ID 了，那么完全就可以顺手把部署的逻辑也给实现了；如果用户自己没能力拿到这个云资源 ID，那么在 certimate 里就填入不了这个参数，自然也无法调用这个接口。如果说是在 certimate 里提供一个跟阿里云 Web 控制台一样的选择面板来选择云资源，这个工作量就很大，对目前的 certimate 来说优先级不高。 > > 综上原因最后没有采用这个方案。 > > 但这个接口确实有两个非常明显的优势： > > * 允许同时部署多个地域下的实例。 > * 支持混合云。 > > 也许等之后 certimate 足够稳定的情况下，才有足够的动机来基于这个服务来实现阿里云的证书部署能力。感谢你的回答，我已经理解了你们的顾虑，你说的确实非常有道理。很期待以后的 certimate，哈哈哈~