1. 问题缘起免费午餐的代价如果你用过阿里云的免费SSL证书那你一定对那个“三个月有效期”的设定又爱又恨。爱的是它确实免费给个人站长、测试环境、小型项目省下了真金白银恨的是每三个月就要手动操作一遍申请、验证、下载、部署的流程一旦忘记网站就会亮起那个刺眼的“不安全”小红锁甚至直接导致服务中断。这感觉就像家里有个需要每季度手动上发条的钟准时是准时但总怕哪天忘了时间就停了。我最初也以为这只是个小麻烦手动操作几次就好。直到有一次一个用于内部API测试的站点证书过期导致整个自动化测试流程中断了大半天我才意识到问题的严重性。这不仅仅是麻烦更是一个潜在的运维风险点。手动续签的不可靠性在项目规模扩大或站点数量增多时会被急剧放大。于是“自动化续签”从一个“锦上添花”的想法变成了一个必须解决的“雪中送炭”的需求。网上方案很多Let‘s Encrypt的ACME协议是主流但对于已经绑定在阿里云生态域名、DNS解析都在阿里云的用户来说直接使用阿里云自己的免费证书并通过其API实现自动化是一条更顺滑、更少“上下文切换”的路径。今天要聊的就是如何利用阿里云现有的工具链搭建一个稳定、可靠的SSL证书自动续签体系真正实现“一次配置长期有效”。2. 核心方案选型为什么是阿里云CLI 脚本面对自动续签通常有几个主流选择使用Certbot等ACME客户端申请Let‘s Encrypt证书、使用第三方证书管理服务或者利用云服务商自身的API。这里我选择了基于阿里云CLI和自有脚本的方案主要基于以下几点考量2.1 环境一致性优先我的域名注册、DNS解析、证书申请全在阿里云平台。使用阿里云CLIAlibaba Cloud CLI和其证书服务API意味着所有操作都在同一个云环境内完成无需将域名的DNS解析权例如添加TXT记录交给外部ACME客户端去验证减少了依赖和潜在的权限风险。对于企业内网或对控制权要求高的场景这一点尤为重要。2.2 免费证书资源的充分利用阿里云提供的单域名免费DV证书虽然只有三个月但申请次数无限制且与阿里云WAF、CDN、SLB等产品集成度非常好。直接续签它可以无缝继承现有的部署配置比如在SLB监听器上直接更新证书ID避免了更换证书品牌或类型可能带来的兼容性检查和额外配置。2.3 可控性与可调试性自己编写Shell或Python脚本调用阿里云CLI整个流程的每一个步骤都清晰可见、完全可控。从触发续签、等待签发、下载证书到部署到服务器你都可以插入日志、告警和异常处理。当出现问题时你可以像调试普通程序一样逐环节排查而不是面对一个封装好的黑盒工具不知所措。2.4 轻量且低成本这个方案的核心就是一个安装了阿里云CLI的轻量级环境比如一台长期运行的ECS甚至一个函数计算FC实例加上一个定时任务Cron。几乎没有额外的服务开销特别适合追求极致成本控制的个人或团队。当然这个方案需要你具备基础的Linux操作和脚本编写能力。但相信我整个搭建过程本身就是一次极佳的运维自动化实践。3. 前期准备配置你的自动化“工作台”工欲善其事必先利其器。在开始编写自动化脚本之前我们需要一个可以执行命令、访问阿里云API的环境。3.1 创建并配置RAM用户直接使用主账号的AccessKey是极不安全的。我们应该创建一个专用于证书操作的RAM用户。登录阿里云控制台进入访问控制RAM。在用户页面点击创建用户。设置用户名例如cert-auto-renew务必勾选“控制台密码登录”和“OpenAPI调用访问”。后者才会生成AccessKey。创建成功后保存好生成的AccessKey ID和AccessKey Secret只显示一次。为用户授权。我们需要两个权限AliyunYundunCertFullAccess管理数字证书服务云盾的权限用于申请、下载证书。AliyunDNSFullAccess管理云解析DNS的权限。虽然阿里云免费证书目前多采用“文件验证”但保留DNS权限是为未来可能的变化或使用其他验证方式做准备也更符合最小权限原则里的“前瞻性”。你可以创建自定义策略将权限范围缩小到特定域名。注意AccessKey Secret如同密码必须妥善保管。建议在后续脚本中使用环境变量或阿里云CLI的配置功能来管理切勿硬编码在脚本中。3.2 安装并配置阿里云CLI我们需要一个Linux环境来运行CLI。可以选择一台长期开机的ECS或者一个轻量应用服务器。安装CLI# 使用curl下载安装脚本并执行以Linux x86_64为例 curl -O https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-amd64.tgz tar xzvf aliyun-cli-linux-latest-amd64.tgz sudo cp aliyun /usr/local/bin/配置CLI# 运行配置命令依次填入RAM用户的AccessKey ID、Secret、默认地域如cn-hangzhou aliyun configure配置完成后可以运行aliyun help测试是否安装成功。3.3 准备证书部署的目标环境想清楚你的证书最终要部署到哪里。常见场景有云服务器ECS/Nginx证书文件.pem, .key需要被上传到服务器特定目录并重载Nginx。负载均衡SLB直接在SLB控制台更新证书或通过API更新监听器绑定的证书ID。容器服务ACK更新Ingress或Secret资源。CDN更新域名配置中的证书。我们的自动化脚本需要包含“部署”这一步。本文将重点演示最经典的ECS Nginx场景其他场景的原理相通只需替换对应的部署命令或API调用。4. 自动化续签脚本核心逻辑拆解整个自动续签流程可以分解为以下几个核心步骤我们将用一个Bash Shell脚本将其串联起来。这个脚本将是自动化的心脏。4.1 步骤一检查证书状态与触发续签阿里云免费证书不能直接“续签”旧证书而是需要为同一个域名重新申请一张新证书。因此我们的逻辑是在旧证书过期前例如提前30天检查域名是否存在有效的未过期证书。如果不存在或即将过期则发起新证书申请。#!/bin/bash # 定义变量 DOMAINyourdomain.com # 你的域名 EMAILadminyourdomain.com # 证书联系人邮箱 ALIYUN_CLI/usr/local/bin/aliyun # 阿里云CLI路径 CERT_DIR/opt/ssl_certs # 本地证书存储目录 DEPLOY_SCRIPT/opt/deploy_cert.sh # 证书部署脚本 # 创建目录 mkdir -p $CERT_DIR # 函数记录日志 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 } # 核心逻辑开始 log 开始SSL证书自动续签流程域名: $DOMAIN # 尝试获取该域名现有的免费证书列表这里简化处理实际应过滤状态为“已签发”且未过期的 # 注意阿里云CLI证书列表查询可能需要较复杂的过滤此处为示例实战中你可能需要解析JSON并处理。 EXISTING_CERT_INFO$($ALIYUN_CLI yundun-cert DescribeUserCertificateList --Domain $DOMAIN --CurrentPage 1 --PageSize 10) # 解析JSON判断是否有有效证书。这里假设我们使用一个更直接的方式总是尝试申请。 # 更严谨的做法是解析 EXISTING_CERT_INFO找到有效期结束时间与当前时间比较。4.2 步骤二申请新证书使用阿里云CLI调用申请免费证书的接口。免费证书的ProductCode是free。log 正在为域名 $DOMAIN 申请新的免费SSL证书... APPLY_RESPONSE$($ALIYUN_CLI yundun-cert CreateUserCertificate --Domain $DOMAIN --ProductCode free --Username $EMAIL --Output json) # 解析返回的JSON获取证书IDCertId CERT_ID$(echo $APPLY_RESPONSE | grep -o CertId:[^]* | cut -d -f4) if [ -z $CERT_ID ]; then log 错误申请证书失败响应: $APPLY_RESPONSE exit 1 fi log 证书申请提交成功证书ID: $CERT_ID4.3 步骤三等待证书签发并下载证书申请后CA机构需要进行域名验证通常是文件验证。阿里云会自动完成验证流程我们需要轮询证书状态直到变为“已签发”。# 等待证书签发的函数 wait_for_issuance() { local cert_id$1 local max_retries30 # 最大重试30次 local retry_interval10 # 每次间隔10秒 for ((i1; imax_retries; i)); do log 等待证书签发尝试第 $i/$max_retries 次... STATUS_RESPONSE$($ALIYUN_CLI yundun-cert DescribeUserCertificateDetail --CertId $cert_id --Output json) CERT_STATUS$(echo $STATUS_RESPONSE | grep -o Status:[^]* | cut -d -f4) if [ $CERT_STATUS issued ]; then log 证书已签发成功 return 0 elif [ $CERT_STATUS failed ] || [ $CERT_STATUS canceled ]; then log 错误证书申请失败或已取消状态: $CERT_STATUS return 1 fi sleep $retry_interval done log 错误等待证书签发超时。 return 1 } # 调用等待函数 if ! wait_for_issuance $CERT_ID; then exit 1 fi证书签发后下载包含证书链和私钥的PEM文件包。log 证书已签发开始下载... DOWNLOAD_RESPONSE$($ALIYUN_CLI yundun-cert DescribeUserCertificateDetail --CertId $CERT_ID --Output json) # 解析下载链接示例实际API返回字段可能不同请以阿里云官方文档为准 # 假设返回的JSON中有 DownloadUrl 字段 DOWNLOAD_URL$(echo $DOWNLOAD_RESPONSE | grep -o DownloadUrl:[^]* | cut -d -f4 | sed s/\\//g) if [ -z $DOWNLOAD_URL ]; then # 如果API不直接提供链接则可能需要调用另一个下载接口 log 尝试通过下载接口获取证书包... $ALIYUN_CLI yundun-cert DownloadUserCertificate --CertId $CERT_ID --Output file --filepath $CERT_DIR/cert_$CERT_ID.zip else wget -O $CERT_DIR/cert_$CERT_ID.zip $DOWNLOAD_URL fi if [ ! -f $CERT_DIR/cert_$CERT_ID.zip ]; then log 错误下载证书包失败。 exit 1 fi log 证书包下载完成: $CERT_DIR/cert_$CERT_ID.zip4.4 步骤四解压并处理证书文件下载的ZIP包内通常包含两个文件yourdomain.com.pem证书链和yourdomain.com.key私钥。我们需要解压并重命名它们以便后续部署。# 解压到临时目录 UNZIP_DIR$CERT_DIR/$CERT_ID mkdir -p $UNZIP_DIR unzip -o $CERT_DIR/cert_$CERT_ID.zip -d $UNZIP_DIR # 找到解压后的文件 CERT_FILE$(find $UNZIP_DIR -name *.pem | head -n 1) KEY_FILE$(find $UNZIP_DIR -name *.key | head -n 1) if [ ! -f $CERT_FILE ] || [ ! -f $KEY_FILE ]; then log 错误在解压包中未找到证书或私钥文件。 exit 1 fi # 将文件复制或移动到标准位置并以域名命名 FINAL_CERT$CERT_DIR/$DOMAIN.crt FINAL_KEY$CERT_DIR/$DOMAIN.key cp $CERT_FILE $FINAL_CERT cp $KEY_FILE $FINAL_KEY log 证书文件已处理: $FINAL_CERT, $FINAL_KEY4.5 步骤五部署证书到目标服务这是最关键的一步需要根据你的实际架构来编写。以下是一个部署到同一台服务器Nginx的示例# 假设Nginx的证书存放路径 NGINX_CERT_DIR/etc/nginx/ssl sudo mkdir -p $NGINX_CERT_DIR # 备份旧证书可选但推荐 sudo cp $NGINX_CERT_DIR/$DOMAIN.crt $NGINX_CERT_DIR/$DOMAIN.crt.bak.$(date %Y%m%d) 2/dev/null || true sudo cp $NGINX_CERT_DIR/$DOMAIN.key $NGINX_CERT_DIR/$DOMAIN.key.bak.$(date %Y%m%d) 2/dev/null || true # 部署新证书 sudo cp $FINAL_CERT $NGINX_CERT_DIR/ sudo cp $FINAL_KEY $NGINX_CERT_DIR/ sudo chmod 600 $NGINX_CERT_DIR/$DOMAIN.key # 确保私钥权限安全 # 重载Nginx配置 log 正在重载Nginx服务... sudo nginx -t sudo systemctl reload nginx if [ $? -eq 0 ]; then log Nginx重载成功新证书已生效。 else log 错误Nginx配置测试失败已回滚证书文件。 # 回滚操作这里简化实际应更严谨 sudo cp $NGINX_CERT_DIR/$DOMAIN.crt.bak.$(date %Y%m%d) $NGINX_CERT_DIR/$DOMAIN.crt 2/dev/null || true sudo cp $NGINX_CERT_DIR/$DOMAIN.key.bak.$(date %Y%m%d) $NGINX_CERT_DIR/$DOMAIN.key 2/dev/null || true exit 1 fi4.6 步骤六清理与通知清理临时文件并可以集成邮件、钉钉、企业微信等通知机制告知管理员证书已成功更新。# 清理临时解压目录和ZIP包 rm -rf $UNZIP_DIR rm -f $CERT_DIR/cert_$CERT_ID.zip log 临时文件已清理。 # 发送成功通知示例写入日志可扩展为调用webhook log SSL证书自动续签流程全部完成域名 $DOMAIN 的证书已更新并部署。 # 此处可以调用 curl 发送通知到你的告警平台 # curl -X POST -H Content-Type: application/json -d {msg:证书更新成功} YOUR_WEBHOOK_URL将以上所有代码块按逻辑顺序组合并填充你的实际变量域名、邮箱、路径等就形成了一个完整的自动化续签脚本例如auto_renew_ssl.sh。记得给它加上执行权限chmod x auto_renew_ssl.sh。5. 实战部署与调度让脚本自己跑起来脚本写好了我们需要让它定期自动执行。最经典的方式就是利用Linux系统的Cron定时任务。5.1 配置Cron定时任务编辑当前用户的Crontabcrontab -e添加一行例如设置为每月1号和15号的凌晨2点30分执行并检查证书是否在30天内过期这个检查逻辑需要你在脚本开头实现或使用更简单的“直接申请”策略。# 每月1号和15号凌晨2:30执行证书续签脚本并将所有输出重定向到日志文件 30 2 1,15 * * /bin/bash /path/to/your/auto_renew_ssl.sh /var/log/ssl_auto_renew.log 21更推荐的策略编写一个“检查-决策”脚本主控脚本它首先检查现有证书的过期时间只有在证书剩余有效期小于30天时才调用上面的续签脚本。这样避免不必要的申请。5.2 使用Systemd Timer更现代的管理方式对于追求更规范管理的系统可以使用Systemd Timer。创建服务单元文件/etc/systemd/system/ssl-renew.service[Unit] DescriptionAuto renew SSL certificate for mydomain Afternetwork.target [Service] Typeoneshot ExecStart/path/to/your/auto_renew_ssl.sh Userroot # 或以一个有权限的非root用户运行创建定时器单元文件/etc/systemd/system/ssl-renew.timer[Unit] DescriptionRun SSL renew monthly [Timer] OnCalendar*-*-1,15 02:30:00 Persistenttrue [Install] WantedBytimers.target启用并启动定时器sudo systemctl daemon-reload sudo systemctl enable --now ssl-renew.timer sudo systemctl list-timers # 查看定时器状态Systemd Timer的优势在于有更强大的日志集成通过journalctl -u ssl-renew.service查看并且可以处理更复杂的时间调度规则。6. 关键细节、避坑指南与高可用考量自动化流程搭建起来不难但要保证其长期稳定运行以下几个细节和“坑”必须注意。6.1 证书验证方式与阿里云API的稳定性阿里云免费证书的验证方式可能会变化。早期多用DNS验证现在多为文件验证。我们的脚本依赖于阿里云自动完成验证。这意味着你的域名必须已经成功在阿里云备案如果是国内服务器并且解析正常。API的稳定性是基础建议在脚本中加入对阿里云CLI命令返回值的详细判断和重试机制。6.2 私钥安全是生命线脚本中会处理私钥文件.key。务必确保脚本存储和运行的目录权限严格避免其他用户读取。最终部署到服务器如Nginx后私钥文件权限应设置为600仅所有者可读可写。考虑使用加密的凭据管理服务如阿里云KMS来动态获取AccessKey而不是将其明文存储在服务器上。6.3 部署环节的原子性与回滚在部署证书到Nginx时我们采用了“先测试再重载”的方式nginx -t systemctl reload nginx。这是最基本的原子性操作。但在生产环境中这还不够。更稳健的做法是将新证书文件部署到一个临时位置。使用nginx -t -c /path/to/new/nginx.conf测试一个包含新证书路径的临时配置。测试通过后再用一个原子操作如mv替换线上的证书文件然后重载。始终保留最近2-3个版本的旧证书备份并在脚本中实现一键回滚功能。6.4 跨服务器部署场景如果你的证书需要部署到多台后端服务器或者SLB、CDN等云产品脚本需要相应扩展。多台ECS可以使用Ansible、SaltStack等配置管理工具在证书更新后触发一个Playbook将证书文件分发到所有目标服务器并重载服务。阿里云SLB使用阿里云CLI的slb模块命令通过UploadServerCertificate上传证书然后使用SetListenerAttribute更新HTTPS监听器绑定的证书ID。注意SLB的证书是独立管理的与证书服务里的证书不同需要上传。函数计算FC/容器服务ACK通常需要更新其配置中的证书ARN或Secret。这需要调用对应的API。6.5 监控与告警闭环的最后一步自动化不能代替监控。你必须设置监控来确认自动化任务确实成功了。脚本执行监控在Cron或Systemd Timer的执行命令后添加状态上报。例如执行成功后调用一个健康检查接口失败时发送告警。证书过期监控使用独立的监控工具如Prometheus Blackbox Exporter、UptimeRobot等定期检查网站SSL证书的过期时间并在证书过期前N天如15天、7天发出告警。这是对自动续签流程的双重保障。日志集中分析将脚本输出的日志/var/log/ssl_auto_renew.log接入ELK或Graylog等日志系统便于排查问题。6.6 处理“申请过于频繁”的限制虽然阿里云免费证书没有明确的总申请次数限制但短时间内对同一域名频繁申请可能会触发风控。我们的定时任务设置为每月两次是相对安全的频率。如果在调试期间需要多次申请建议先使用测试域名或间隔一段时间再试。7. 方案优化与进阶思路基础的跑通只是开始要让这个体系更健壮可以考虑以下优化方向。7.1 从Shell脚本到Python/Go实现对于更复杂的逻辑如JSON解析、错误重试、多域名批量处理、状态机管理使用Python或Go编写是更好的选择。阿里云也提供了完善的SDK如Python SDKaliyun-python-sdk-core代码可读性和可维护性会更强。你可以用Python的subprocess调用阿里云CLI或者直接使用SDK调用API。7.2 与基础设施即代码IaC结合如果你的服务器架构是用Terraform、Pulumi等IaC工具管理的可以考虑将证书申请和初始部署也纳入IaC流程。自动续签则作为运维阶段的独立流程。两者结合实现从创建到运维的全生命周期自动化。7.3 使用Serverless函数计算FC如果你不想维护一台长期运行的ECS可以将续签脚本部署到阿里云函数计算FC。FC可以配置定时触发器每月执行一次。你需要将证书文件最终上传到OSS然后通过内网或脚本通知你的服务器从OSS拉取并部署新证书。这实现了真正的“无服务器”自动化成本可能更低。7.4 多域名与泛域名证书管理上述脚本是针对单个域名的。如果你有多个域名甚至需要泛域名证书脚本需要改造为循环处理一个域名列表。对于泛域名证书阿里云免费证书不支持你需要购买付费证书或使用Let‘s Encrypt通过DNS验证。这时你的脚本就需要集成阿里云DNS的API来自动添加和删除TXT记录复杂度会上升一个等级。7.5 建立证书仓库将所有证书包括私钥加密后存储在一个安全的中央仓库中如HashiCorp Vault或阿里云KMS。应用程序或部署脚本从仓库中动态获取证书而不是存放在每台服务器的文件系统里。这大大提升了密钥管理的安全性和合规性。整个自动续签体系的搭建是一个典型的“运维即代码”实践。它开始可能只是一个简单的脚本但随着你对可靠性、安全性和扩展性要求的提高它会逐渐演变成一个包含状态管理、错误处理、多环境支持、安全审计的小型系统。这个过程本身就是对云原生运维能力的一次扎实锻炼。当你看到证书在凌晨悄无声息地更新完毕而网站全天候稳定运行时那种一切尽在掌控的安心感就是自动化带来的最大回报。
1. 问题缘起免费午餐的代价如果你用过阿里云的免费SSL证书那你一定对那个“三个月有效期”的设定又爱又恨。爱的是它确实免费给个人站长、测试环境、小型项目省下了真金白银恨的是每三个月就要手动操作一遍申请、验证、下载、部署的流程一旦忘记网站就会亮起那个刺眼的“不安全”小红锁甚至直接导致服务中断。这感觉就像家里有个需要每季度手动上发条的钟准时是准时但总怕哪天忘了时间就停了。我最初也以为这只是个小麻烦手动操作几次就好。直到有一次一个用于内部API测试的站点证书过期导致整个自动化测试流程中断了大半天我才意识到问题的严重性。这不仅仅是麻烦更是一个潜在的运维风险点。手动续签的不可靠性在项目规模扩大或站点数量增多时会被急剧放大。于是“自动化续签”从一个“锦上添花”的想法变成了一个必须解决的“雪中送炭”的需求。网上方案很多Let‘s Encrypt的ACME协议是主流但对于已经绑定在阿里云生态域名、DNS解析都在阿里云的用户来说直接使用阿里云自己的免费证书并通过其API实现自动化是一条更顺滑、更少“上下文切换”的路径。今天要聊的就是如何利用阿里云现有的工具链搭建一个稳定、可靠的SSL证书自动续签体系真正实现“一次配置长期有效”。2. 核心方案选型为什么是阿里云CLI 脚本面对自动续签通常有几个主流选择使用Certbot等ACME客户端申请Let‘s Encrypt证书、使用第三方证书管理服务或者利用云服务商自身的API。这里我选择了基于阿里云CLI和自有脚本的方案主要基于以下几点考量2.1 环境一致性优先我的域名注册、DNS解析、证书申请全在阿里云平台。使用阿里云CLIAlibaba Cloud CLI和其证书服务API意味着所有操作都在同一个云环境内完成无需将域名的DNS解析权例如添加TXT记录交给外部ACME客户端去验证减少了依赖和潜在的权限风险。对于企业内网或对控制权要求高的场景这一点尤为重要。2.2 免费证书资源的充分利用阿里云提供的单域名免费DV证书虽然只有三个月但申请次数无限制且与阿里云WAF、CDN、SLB等产品集成度非常好。直接续签它可以无缝继承现有的部署配置比如在SLB监听器上直接更新证书ID避免了更换证书品牌或类型可能带来的兼容性检查和额外配置。2.3 可控性与可调试性自己编写Shell或Python脚本调用阿里云CLI整个流程的每一个步骤都清晰可见、完全可控。从触发续签、等待签发、下载证书到部署到服务器你都可以插入日志、告警和异常处理。当出现问题时你可以像调试普通程序一样逐环节排查而不是面对一个封装好的黑盒工具不知所措。2.4 轻量且低成本这个方案的核心就是一个安装了阿里云CLI的轻量级环境比如一台长期运行的ECS甚至一个函数计算FC实例加上一个定时任务Cron。几乎没有额外的服务开销特别适合追求极致成本控制的个人或团队。当然这个方案需要你具备基础的Linux操作和脚本编写能力。但相信我整个搭建过程本身就是一次极佳的运维自动化实践。3. 前期准备配置你的自动化“工作台”工欲善其事必先利其器。在开始编写自动化脚本之前我们需要一个可以执行命令、访问阿里云API的环境。3.1 创建并配置RAM用户直接使用主账号的AccessKey是极不安全的。我们应该创建一个专用于证书操作的RAM用户。登录阿里云控制台进入访问控制RAM。在用户页面点击创建用户。设置用户名例如cert-auto-renew务必勾选“控制台密码登录”和“OpenAPI调用访问”。后者才会生成AccessKey。创建成功后保存好生成的AccessKey ID和AccessKey Secret只显示一次。为用户授权。我们需要两个权限AliyunYundunCertFullAccess管理数字证书服务云盾的权限用于申请、下载证书。AliyunDNSFullAccess管理云解析DNS的权限。虽然阿里云免费证书目前多采用“文件验证”但保留DNS权限是为未来可能的变化或使用其他验证方式做准备也更符合最小权限原则里的“前瞻性”。你可以创建自定义策略将权限范围缩小到特定域名。注意AccessKey Secret如同密码必须妥善保管。建议在后续脚本中使用环境变量或阿里云CLI的配置功能来管理切勿硬编码在脚本中。3.2 安装并配置阿里云CLI我们需要一个Linux环境来运行CLI。可以选择一台长期开机的ECS或者一个轻量应用服务器。安装CLI# 使用curl下载安装脚本并执行以Linux x86_64为例 curl -O https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-amd64.tgz tar xzvf aliyun-cli-linux-latest-amd64.tgz sudo cp aliyun /usr/local/bin/配置CLI# 运行配置命令依次填入RAM用户的AccessKey ID、Secret、默认地域如cn-hangzhou aliyun configure配置完成后可以运行aliyun help测试是否安装成功。3.3 准备证书部署的目标环境想清楚你的证书最终要部署到哪里。常见场景有云服务器ECS/Nginx证书文件.pem, .key需要被上传到服务器特定目录并重载Nginx。负载均衡SLB直接在SLB控制台更新证书或通过API更新监听器绑定的证书ID。容器服务ACK更新Ingress或Secret资源。CDN更新域名配置中的证书。我们的自动化脚本需要包含“部署”这一步。本文将重点演示最经典的ECS Nginx场景其他场景的原理相通只需替换对应的部署命令或API调用。4. 自动化续签脚本核心逻辑拆解整个自动续签流程可以分解为以下几个核心步骤我们将用一个Bash Shell脚本将其串联起来。这个脚本将是自动化的心脏。4.1 步骤一检查证书状态与触发续签阿里云免费证书不能直接“续签”旧证书而是需要为同一个域名重新申请一张新证书。因此我们的逻辑是在旧证书过期前例如提前30天检查域名是否存在有效的未过期证书。如果不存在或即将过期则发起新证书申请。#!/bin/bash # 定义变量 DOMAINyourdomain.com # 你的域名 EMAILadminyourdomain.com # 证书联系人邮箱 ALIYUN_CLI/usr/local/bin/aliyun # 阿里云CLI路径 CERT_DIR/opt/ssl_certs # 本地证书存储目录 DEPLOY_SCRIPT/opt/deploy_cert.sh # 证书部署脚本 # 创建目录 mkdir -p $CERT_DIR # 函数记录日志 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 } # 核心逻辑开始 log 开始SSL证书自动续签流程域名: $DOMAIN # 尝试获取该域名现有的免费证书列表这里简化处理实际应过滤状态为“已签发”且未过期的 # 注意阿里云CLI证书列表查询可能需要较复杂的过滤此处为示例实战中你可能需要解析JSON并处理。 EXISTING_CERT_INFO$($ALIYUN_CLI yundun-cert DescribeUserCertificateList --Domain $DOMAIN --CurrentPage 1 --PageSize 10) # 解析JSON判断是否有有效证书。这里假设我们使用一个更直接的方式总是尝试申请。 # 更严谨的做法是解析 EXISTING_CERT_INFO找到有效期结束时间与当前时间比较。4.2 步骤二申请新证书使用阿里云CLI调用申请免费证书的接口。免费证书的ProductCode是free。log 正在为域名 $DOMAIN 申请新的免费SSL证书... APPLY_RESPONSE$($ALIYUN_CLI yundun-cert CreateUserCertificate --Domain $DOMAIN --ProductCode free --Username $EMAIL --Output json) # 解析返回的JSON获取证书IDCertId CERT_ID$(echo $APPLY_RESPONSE | grep -o CertId:[^]* | cut -d -f4) if [ -z $CERT_ID ]; then log 错误申请证书失败响应: $APPLY_RESPONSE exit 1 fi log 证书申请提交成功证书ID: $CERT_ID4.3 步骤三等待证书签发并下载证书申请后CA机构需要进行域名验证通常是文件验证。阿里云会自动完成验证流程我们需要轮询证书状态直到变为“已签发”。# 等待证书签发的函数 wait_for_issuance() { local cert_id$1 local max_retries30 # 最大重试30次 local retry_interval10 # 每次间隔10秒 for ((i1; imax_retries; i)); do log 等待证书签发尝试第 $i/$max_retries 次... STATUS_RESPONSE$($ALIYUN_CLI yundun-cert DescribeUserCertificateDetail --CertId $cert_id --Output json) CERT_STATUS$(echo $STATUS_RESPONSE | grep -o Status:[^]* | cut -d -f4) if [ $CERT_STATUS issued ]; then log 证书已签发成功 return 0 elif [ $CERT_STATUS failed ] || [ $CERT_STATUS canceled ]; then log 错误证书申请失败或已取消状态: $CERT_STATUS return 1 fi sleep $retry_interval done log 错误等待证书签发超时。 return 1 } # 调用等待函数 if ! wait_for_issuance $CERT_ID; then exit 1 fi证书签发后下载包含证书链和私钥的PEM文件包。log 证书已签发开始下载... DOWNLOAD_RESPONSE$($ALIYUN_CLI yundun-cert DescribeUserCertificateDetail --CertId $CERT_ID --Output json) # 解析下载链接示例实际API返回字段可能不同请以阿里云官方文档为准 # 假设返回的JSON中有 DownloadUrl 字段 DOWNLOAD_URL$(echo $DOWNLOAD_RESPONSE | grep -o DownloadUrl:[^]* | cut -d -f4 | sed s/\\//g) if [ -z $DOWNLOAD_URL ]; then # 如果API不直接提供链接则可能需要调用另一个下载接口 log 尝试通过下载接口获取证书包... $ALIYUN_CLI yundun-cert DownloadUserCertificate --CertId $CERT_ID --Output file --filepath $CERT_DIR/cert_$CERT_ID.zip else wget -O $CERT_DIR/cert_$CERT_ID.zip $DOWNLOAD_URL fi if [ ! -f $CERT_DIR/cert_$CERT_ID.zip ]; then log 错误下载证书包失败。 exit 1 fi log 证书包下载完成: $CERT_DIR/cert_$CERT_ID.zip4.4 步骤四解压并处理证书文件下载的ZIP包内通常包含两个文件yourdomain.com.pem证书链和yourdomain.com.key私钥。我们需要解压并重命名它们以便后续部署。# 解压到临时目录 UNZIP_DIR$CERT_DIR/$CERT_ID mkdir -p $UNZIP_DIR unzip -o $CERT_DIR/cert_$CERT_ID.zip -d $UNZIP_DIR # 找到解压后的文件 CERT_FILE$(find $UNZIP_DIR -name *.pem | head -n 1) KEY_FILE$(find $UNZIP_DIR -name *.key | head -n 1) if [ ! -f $CERT_FILE ] || [ ! -f $KEY_FILE ]; then log 错误在解压包中未找到证书或私钥文件。 exit 1 fi # 将文件复制或移动到标准位置并以域名命名 FINAL_CERT$CERT_DIR/$DOMAIN.crt FINAL_KEY$CERT_DIR/$DOMAIN.key cp $CERT_FILE $FINAL_CERT cp $KEY_FILE $FINAL_KEY log 证书文件已处理: $FINAL_CERT, $FINAL_KEY4.5 步骤五部署证书到目标服务这是最关键的一步需要根据你的实际架构来编写。以下是一个部署到同一台服务器Nginx的示例# 假设Nginx的证书存放路径 NGINX_CERT_DIR/etc/nginx/ssl sudo mkdir -p $NGINX_CERT_DIR # 备份旧证书可选但推荐 sudo cp $NGINX_CERT_DIR/$DOMAIN.crt $NGINX_CERT_DIR/$DOMAIN.crt.bak.$(date %Y%m%d) 2/dev/null || true sudo cp $NGINX_CERT_DIR/$DOMAIN.key $NGINX_CERT_DIR/$DOMAIN.key.bak.$(date %Y%m%d) 2/dev/null || true # 部署新证书 sudo cp $FINAL_CERT $NGINX_CERT_DIR/ sudo cp $FINAL_KEY $NGINX_CERT_DIR/ sudo chmod 600 $NGINX_CERT_DIR/$DOMAIN.key # 确保私钥权限安全 # 重载Nginx配置 log 正在重载Nginx服务... sudo nginx -t sudo systemctl reload nginx if [ $? -eq 0 ]; then log Nginx重载成功新证书已生效。 else log 错误Nginx配置测试失败已回滚证书文件。 # 回滚操作这里简化实际应更严谨 sudo cp $NGINX_CERT_DIR/$DOMAIN.crt.bak.$(date %Y%m%d) $NGINX_CERT_DIR/$DOMAIN.crt 2/dev/null || true sudo cp $NGINX_CERT_DIR/$DOMAIN.key.bak.$(date %Y%m%d) $NGINX_CERT_DIR/$DOMAIN.key 2/dev/null || true exit 1 fi4.6 步骤六清理与通知清理临时文件并可以集成邮件、钉钉、企业微信等通知机制告知管理员证书已成功更新。# 清理临时解压目录和ZIP包 rm -rf $UNZIP_DIR rm -f $CERT_DIR/cert_$CERT_ID.zip log 临时文件已清理。 # 发送成功通知示例写入日志可扩展为调用webhook log SSL证书自动续签流程全部完成域名 $DOMAIN 的证书已更新并部署。 # 此处可以调用 curl 发送通知到你的告警平台 # curl -X POST -H Content-Type: application/json -d {msg:证书更新成功} YOUR_WEBHOOK_URL将以上所有代码块按逻辑顺序组合并填充你的实际变量域名、邮箱、路径等就形成了一个完整的自动化续签脚本例如auto_renew_ssl.sh。记得给它加上执行权限chmod x auto_renew_ssl.sh。5. 实战部署与调度让脚本自己跑起来脚本写好了我们需要让它定期自动执行。最经典的方式就是利用Linux系统的Cron定时任务。5.1 配置Cron定时任务编辑当前用户的Crontabcrontab -e添加一行例如设置为每月1号和15号的凌晨2点30分执行并检查证书是否在30天内过期这个检查逻辑需要你在脚本开头实现或使用更简单的“直接申请”策略。# 每月1号和15号凌晨2:30执行证书续签脚本并将所有输出重定向到日志文件 30 2 1,15 * * /bin/bash /path/to/your/auto_renew_ssl.sh /var/log/ssl_auto_renew.log 21更推荐的策略编写一个“检查-决策”脚本主控脚本它首先检查现有证书的过期时间只有在证书剩余有效期小于30天时才调用上面的续签脚本。这样避免不必要的申请。5.2 使用Systemd Timer更现代的管理方式对于追求更规范管理的系统可以使用Systemd Timer。创建服务单元文件/etc/systemd/system/ssl-renew.service[Unit] DescriptionAuto renew SSL certificate for mydomain Afternetwork.target [Service] Typeoneshot ExecStart/path/to/your/auto_renew_ssl.sh Userroot # 或以一个有权限的非root用户运行创建定时器单元文件/etc/systemd/system/ssl-renew.timer[Unit] DescriptionRun SSL renew monthly [Timer] OnCalendar*-*-1,15 02:30:00 Persistenttrue [Install] WantedBytimers.target启用并启动定时器sudo systemctl daemon-reload sudo systemctl enable --now ssl-renew.timer sudo systemctl list-timers # 查看定时器状态Systemd Timer的优势在于有更强大的日志集成通过journalctl -u ssl-renew.service查看并且可以处理更复杂的时间调度规则。6. 关键细节、避坑指南与高可用考量自动化流程搭建起来不难但要保证其长期稳定运行以下几个细节和“坑”必须注意。6.1 证书验证方式与阿里云API的稳定性阿里云免费证书的验证方式可能会变化。早期多用DNS验证现在多为文件验证。我们的脚本依赖于阿里云自动完成验证。这意味着你的域名必须已经成功在阿里云备案如果是国内服务器并且解析正常。API的稳定性是基础建议在脚本中加入对阿里云CLI命令返回值的详细判断和重试机制。6.2 私钥安全是生命线脚本中会处理私钥文件.key。务必确保脚本存储和运行的目录权限严格避免其他用户读取。最终部署到服务器如Nginx后私钥文件权限应设置为600仅所有者可读可写。考虑使用加密的凭据管理服务如阿里云KMS来动态获取AccessKey而不是将其明文存储在服务器上。6.3 部署环节的原子性与回滚在部署证书到Nginx时我们采用了“先测试再重载”的方式nginx -t systemctl reload nginx。这是最基本的原子性操作。但在生产环境中这还不够。更稳健的做法是将新证书文件部署到一个临时位置。使用nginx -t -c /path/to/new/nginx.conf测试一个包含新证书路径的临时配置。测试通过后再用一个原子操作如mv替换线上的证书文件然后重载。始终保留最近2-3个版本的旧证书备份并在脚本中实现一键回滚功能。6.4 跨服务器部署场景如果你的证书需要部署到多台后端服务器或者SLB、CDN等云产品脚本需要相应扩展。多台ECS可以使用Ansible、SaltStack等配置管理工具在证书更新后触发一个Playbook将证书文件分发到所有目标服务器并重载服务。阿里云SLB使用阿里云CLI的slb模块命令通过UploadServerCertificate上传证书然后使用SetListenerAttribute更新HTTPS监听器绑定的证书ID。注意SLB的证书是独立管理的与证书服务里的证书不同需要上传。函数计算FC/容器服务ACK通常需要更新其配置中的证书ARN或Secret。这需要调用对应的API。6.5 监控与告警闭环的最后一步自动化不能代替监控。你必须设置监控来确认自动化任务确实成功了。脚本执行监控在Cron或Systemd Timer的执行命令后添加状态上报。例如执行成功后调用一个健康检查接口失败时发送告警。证书过期监控使用独立的监控工具如Prometheus Blackbox Exporter、UptimeRobot等定期检查网站SSL证书的过期时间并在证书过期前N天如15天、7天发出告警。这是对自动续签流程的双重保障。日志集中分析将脚本输出的日志/var/log/ssl_auto_renew.log接入ELK或Graylog等日志系统便于排查问题。6.6 处理“申请过于频繁”的限制虽然阿里云免费证书没有明确的总申请次数限制但短时间内对同一域名频繁申请可能会触发风控。我们的定时任务设置为每月两次是相对安全的频率。如果在调试期间需要多次申请建议先使用测试域名或间隔一段时间再试。7. 方案优化与进阶思路基础的跑通只是开始要让这个体系更健壮可以考虑以下优化方向。7.1 从Shell脚本到Python/Go实现对于更复杂的逻辑如JSON解析、错误重试、多域名批量处理、状态机管理使用Python或Go编写是更好的选择。阿里云也提供了完善的SDK如Python SDKaliyun-python-sdk-core代码可读性和可维护性会更强。你可以用Python的subprocess调用阿里云CLI或者直接使用SDK调用API。7.2 与基础设施即代码IaC结合如果你的服务器架构是用Terraform、Pulumi等IaC工具管理的可以考虑将证书申请和初始部署也纳入IaC流程。自动续签则作为运维阶段的独立流程。两者结合实现从创建到运维的全生命周期自动化。7.3 使用Serverless函数计算FC如果你不想维护一台长期运行的ECS可以将续签脚本部署到阿里云函数计算FC。FC可以配置定时触发器每月执行一次。你需要将证书文件最终上传到OSS然后通过内网或脚本通知你的服务器从OSS拉取并部署新证书。这实现了真正的“无服务器”自动化成本可能更低。7.4 多域名与泛域名证书管理上述脚本是针对单个域名的。如果你有多个域名甚至需要泛域名证书脚本需要改造为循环处理一个域名列表。对于泛域名证书阿里云免费证书不支持你需要购买付费证书或使用Let‘s Encrypt通过DNS验证。这时你的脚本就需要集成阿里云DNS的API来自动添加和删除TXT记录复杂度会上升一个等级。7.5 建立证书仓库将所有证书包括私钥加密后存储在一个安全的中央仓库中如HashiCorp Vault或阿里云KMS。应用程序或部署脚本从仓库中动态获取证书而不是存放在每台服务器的文件系统里。这大大提升了密钥管理的安全性和合规性。整个自动续签体系的搭建是一个典型的“运维即代码”实践。它开始可能只是一个简单的脚本但随着你对可靠性、安全性和扩展性要求的提高它会逐渐演变成一个包含状态管理、错误处理、多环境支持、安全审计的小型系统。这个过程本身就是对云原生运维能力的一次扎实锻炼。当你看到证书在凌晨悄无声息地更新完毕而网站全天候稳定运行时那种一切尽在掌控的安心感就是自动化带来的最大回报。
