TLS Connect 证书下发的目标服务器覆盖Windows Server 与主流 Linux 发行版，但运行管理控制台的那台机器本身必须是 Windows。
TLS Connect 的部署模型里，"控制台装在哪"和"证书推到哪"是两个常被混为一谈的层级。官方网站的产品介绍把这两层揉在一句话讲，官方支持文档（SystemRequirements）又把第一层钉得很死。选型时只问"支不支持 Linux"，很容易只得到一半答案。
证书有效期从 200 天一路压到 47 天（CA/BrowserForum 的分三步走方案），手动续期已经不现实。在把环境接进自动化之前，先把"我的系统能不能被管"这件事问清楚，比问"功能多不多"更靠前。先把管理端和目标端分开，再谈支持范围。
一、先分清两层：跑 TLS Connect 的机器，和收证书的机器
TLS Connect 是一套轻量级的本地化管理工具，不是纯云端代理。它的工作方式是：你在一台机器上装上TLS Connect 控制台，由这台机器统一去申请、签发、续期证书，再把证书分发到你的各个端点。于是自然分出两层。
| 层级 | 角色 | 对操作系统的要求 |
| 管理端 | 安装并运行 TLS Connect 控制台，负责申请、续期、分发 | 只能是 Windows（系统要求明确限定） |
| 目标端 | 接收并部署证书的服务器、负载均衡、云资源等端点 | Windows Server 与主流 Linux 发行版都在列 |
很多"TLS Connect 支不支持Linux"的疑问，其实是把这两层问反了。Linux 能不能"被管"和 Linux 能不能"装控制台"，是两个问题，答案不一样。
问支持范围之前，先确认你问的是管理端还是目标端。
二、管理控制台装在哪里？Windows 是硬门槛
官方支持文档对 TLS Connect 的运行环境写得没有商量余地。运行TLS Connect 必须满足：Windows Server（具备出网访问能力），或者 Windows 10 / Windows 11；运行时要求 .NET10 或更高版本，以及 Microsoft.AspNetCore.App 10.0.3 运行时。
如果走 ACME 通道做证书下发，还有一条附加要求：simple-acme必须和 TLS Connect 装在同一台服务器上。视网络情况，可能还要装 simple-acme 的 Cloudflare 或 GoDaddy DNS 校验插件，以及Azure Key Vault 存储插件。
管理中枢因此必须是一台 Windows 机器：它不需要多强，但要能出网、能接收来自内网各端点的入站连接——因为TLS Connect 要从这台机器把证书推下去。纯 Linux 环境里，没有一台 Windows 主机，TLS Connect 控制台就起不来。
管理中枢必须是 Windows，这条没有替代方案。
三、证书到底能下到哪些服务器系统？
目标端的操作系统范围比管理端宽。官网在 TLS Connect的集成说明里列出：服务器系统支持 Windows Server，以及 Linux（CentOS、Ubuntu、Debian 等主流发行版）。Web 服务器层面则覆盖Nginx、Apache、IIS。
注意一个常被忽略的点：这些目标端不需要安装 TLSConnect 控制台。它们只是"被推送证书"的端点，由那台 Windows 管理机统一编排。所以你内网里那批 Ubuntu 或CentOS 的 Web 服务器，照样可以进入 TLS Connect 的管理范围，前提是它们能被管理机通过网络触达并完成部署。
TLS Connect 面向的是 1 到 100 张SSL/TLS 证书的中小企业场景，底层基于 ACME（Automated Certificate Management Environment，自动化证书管理环境，IETF标准 RFC 8555）。它把域名验证、签发、部署、续期串成一条自动化链路，目标端操作系统只要落在上面那张清单里，就能被纳入。
目标端 Windows Server 与 Linux 都在支持范围，且不必安装控制台。
四、Linux 上没装软件，证书怎么下去？
Linux 端点怎么收到证书，才是问"Linux 支持吗"时真正想搞清楚的事。TLSConnect 借助 ACME 协议从 GlobalSign Atlas（支持 ACME 协议）取得证书，再由其部署机制把证书分发到目标服务器、负载均衡或云平台。目标端的Linux 机器作为"部署对象"被集中管理，而不是作为"管理节点"。
具体到某个发行版、某种 Web 服务，部署时端点侧要不要配合装轻量代理、走HTTP-01 还是 DNS-01 校验，取决于你实际的环境拓扑。官网的集成清单给了大类，但没有把每一种组合的部署细节铺开。遇到这种"特定版本能不能用"的问题，官网自己也建议：联系GlobalSign 中国本地团队，拿一份针对你环境的技术兼容清单来逐条核对。
部署细节不能嫌麻烦。不同 Linux 发行版、不同 Web 服务器版本，证书重载的方式不一样。把"能装控制台"和"能收证书"想当然划等号，上线后才发现某个边缘节点始终收不到新证书，比选型时多问一句贵得多。
目标端部署细节按环境逐条确认，别拿大类清单当免死金牌。
五、除了裸服务器，还能下到哪一类环境？
证书不会只躺在裸服务器上。TLS Connect 的集成范围把证书可能落地的位置基本覆盖了一遍，列出来能帮你判断"我的资产是不是都在管理半径内"。
| 环境类别 | 官网列出的支持对象 |
| Web 服务器 | Nginx、Apache、IIS |
| 负载均衡 | F5、Nginx、HAProxy、各云厂商负载均衡服务 |
| 容器平台 | Kubernetes（配合 cert-manager） |
| 云服务商 | AWS、Google Cloud、Azure 等 |
| 域名与 DNS | 阿里云 DNS、腾讯云 DNSPod、AWS Route 53、Cloudflare |
环境类别与操作系统两项是交叉关系。一台 CentOS 上的Nginx 同时落在"Linux"和"Web 服务器"两个格子里。把证书分发到负载均衡或 CDN 边缘，对最终用户可见的加密质量没有影响，但管理动作发生在不同位置——这也是为什么选型时要先盘清楚证书到底落在哪些地方。
支持范围以"端点的类别"划分，不止看操作系统一项。
六、上线前怎么确认你的系统能不能用？
把上面几层理清楚之后，落到执行就是几件动手就能验证的事。别停在销售说"支持"这一步。
1. 先定管理机。找一台Windows Server 或 Windows 10/11 的机器，确认能装 .NET 10 与 AspNetCore 10.0.3 运行时，且能出网、能被内网端点回访。打算走ACME，就同时规划 simple-acme 同机安装。
2. 列出目标端清单。把要管证书的服务器操作系统逐条列出来：哪几台Windows Server、哪些 Linux 发行版及版本号、跑的是什么 Web 服务。拿这张清单去比对官网集成范围。
3. 对不上就问本地团队。清单里出现官网大类没点名的发行版版本、或小众Web 服务，直接找 GlobalSign 中国要技术兼容清单，按版本逐条确认，不要自己猜。
4. 用真实端点试一次部署。挑一台你确定存在、但不起眼的服务器，走完"申请—签发—部署—重载—浏览器看指纹变化"全链路，确认它真的收到了新证书，而不是只收到"下发成功"的提示。
证书有效期缩短的时间表已经排定，2026 年起步、2029 年全面落地到47 天。自动化不是要不要上的问题，是早装上手里就有缓冲、晚报就得靠人工扛续期峰值的区别。动手前把"系统能不能被管"问透，是这笔投入不跑偏的第一步。
关于 TLS Connect 证书下发的几个常见问题
Q1：TLS Connect 能装在 Linux 上当作管理控制台吗？
不能。官方系统要求限定管理控制台运行在 WindowsServer 或 Windows 10/11 上，需要 .NET 10 与 AspNetCore 10.0.3 运行时。Linux 机器只能作为接收证书的"目标端"被纳入管理，不能充当管理中枢。
Q2：Linux 服务器上需要装什么客户端才能收证书？
目标端本身不需要安装 TLS Connect 控制台。证书通过TLS Connect 的部署机制下发，具体某个 Linux 发行版或 Web 服务在部署时端点侧要不要配合轻量组件、走哪种校验方式，取决于你的环境拓扑，建议以GlobalSign 中国的技术兼容清单为准。
Q3：证书有效期缩短到 47 天后，现有的支持范围还够用吗？
够用，而且更该上。有效期缩短意味着续期频次从一年一次变成约每月一次，能覆盖Windows Server、Linux、负载均衡、云与 CDN 的统一自动化，正好对应这个节奏。真正要补的是上线前的真实端点验证，而不是支持清单本身。
Q4：怎么确认我用的某个特定系统版本在支持清单里？
先用官网列出的大类（Windows Server、Linux 主流发行版、Nginx/Apache/IIS、F5/HAProxy、K8s、AWS/GCP/Azure等）做初筛；出现清单没点名的版本或组合，联系 GlobalSign 中国本地团队获取对应环境的技术兼容清单逐条核对。