首页 / 服务器运维 / certsrv无法访问怎么办:AD

certsrv无法访问怎么办:AD CS Web 注册从 DNS、IIS 到权限的排查实战

Roxi
Roxi 加速器 — 稳定·快速·安全
全球节点覆盖,支持所有主流平台,一键连接无需配置。新用户免费试用。
立即体验 →

第 1 章:OK so,先别重装!我们先判断是哪一层挂了

兄弟们开机!今天我们来现场拆一个很常见但特别容易误判的问题:certsrv无法访问。你在浏览器里敲 http://CA服务器名/certsrvhttps://CA服务器名/certsrv,结果 404、401、403、连接超时,甚至直接白屏。先别急着卸载 AD CS,也别一上来重装 IIS,接下来我带你像录屏排障一样,一层一层把它打穿。

现在看屏幕,我们先把问题分成 4 类:客户端解析问题、网络端口问题、IIS 站点问题、AD CS Web 注册组件问题。你先在客户端 PowerShell 里跑这几条,注意不要跳步骤:

  1. 确认 DNS 解析:nslookup CA服务器名

  2. 确认端口连通:Test-NetConnection CA服务器名 -Port 80Test-NetConnection CA服务器名 -Port 443

  3. 确认路径响应:curl -I http://CA服务器名/certsrv

  4. 确认当前登录域身份:whoami /fqdn

这里给你一个快速判断表,接下来照着看,基本 3 分钟就能定位方向。

现象大概率原因下一步动作
nslookup 失败DNS 或主机名错误检查 DNS 后缀、A 记录、hosts
80/443 端口不通防火墙、IIS 未启动、网络 ACL去服务器检查服务和防火墙
返回 401认证正常触发但权限或登录方式有问题检查 Windows 身份验证和 IE/Edge 区域
返回 404certsrv 虚拟目录不存在检查 AD CS Web Enrollment 是否安装
返回 500ASP/ISAPI/应用池异常查 IIS 日志和事件查看器

第 2 章:Now watch this,客户端 5 个命令直接定性

Q1需求调研Q2产品开发Q3内测上线Q4全面推广

接下来我们在客户端做一个“快测”。我实际在一台 Windows 11 域客户端上测过,内网 1Gbps 环境下,正常访问 /certsrv 的首包一般在 20ms 到 200ms 之间。如果 Test-NetConnection 都卡 5 秒以上,大概率不是证书服务本身,而是网络或防火墙。

第一步,看 DNS。执行:Resolve-DnsName CA服务器名。如果解析到了旧 IP,屏幕上你会看到一个完全不对的地址,这时候刷新 DNS:ipconfig /flushdns。如果公司 DNS 里压根没有记录,那就临时用 hosts 验证:编辑 C:\Windows\System32\drivers\etc\hosts,加一行 10.0.0.10 CA服务器名,保存后再测。

第二步,看端口。执行:Test-NetConnection CA服务器名 -Port 80。如果 TcpTestSucceeded : False,去服务器上开防火墙规则,不要盲目关整个防火墙,直接放 IIS 常用端口:

New-NetFirewallRule -DisplayName "Allow HTTP for certsrv" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow

New-NetFirewallRule -DisplayName "Allow HTTPS for certsrv" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

第三步,看认证。执行:curl -I http://CA服务器名/certsrv。如果你看到 HTTP/1.1 401 Unauthorized,别慌,这反而说明 IIS 活着,认证正在工作。浏览器访问时建议先用 Edge,输入 域\用户名 和密码。如果是域内机器,确保该地址在“本地 Intranet 区域”,否则浏览器可能不会自动传 Windows 凭据。

第 3 章:切到服务器,IIS 和 certsrv 虚拟目录这样查

OK,画面切到 CA 服务器。先看 IIS 是否活着。打开 PowerShell 管理员窗口,执行:Get-Service W3SVC。如果状态不是 Running,直接启动:Start-Service W3SVC。再看 IIS 是否监听端口:netstat -ano | findstr ":80",正常你应该能看到 LISTENING

接下来关键来了:certsrv 不是凭空存在的,它依赖 AD CS 的 Web Enrollment 角色服务。执行:Get-WindowsFeature ADCS-Web-Enrollment,Web-Server,Web-Windows-Auth,Web-Asp-Net45。如果 ADCS-Web-Enrollment 没安装,浏览器访问 /certsrv 返回 404 就非常合理。安装命令如下:

Install-WindowsFeature ADCS-Web-Enrollment -IncludeManagementTools

装完别急着关窗口,继续跑配置向导。如果是已有企业 CA,一般用:

Install-AdcsWebEnrollment -CAConfig "CA服务器名\CA名称"

如果你不知道 CA 名称,执行:certutil -config - -ping,系统会弹出可用 CA 列表。这里很多人踩坑:服务器名写对了,但 CA 公用名称写错,结果 Web 注册页面能开,提交申请时报错。我们要的是完整格式,比如 CA01\corp-CA01-CA

第 4 章:401、403、500 分开修,别把权限问题当网络问题

🔧STEP 1环境搭建🚀STEP 2编码实现📋STEP 3测试验证⚙️STEP 4部署上线

现在进入最刺激的部分:页面能出来,但登录或提交证书申请失败。先看 401。打开 IIS 管理器,找到 Default Web Site 下面的 certsrv,点“身份验证”。正常情况下,Windows 身份验证启用,匿名身份验证通常禁用。你也可以用命令看:

%windir%\system32\inetsrv\appcmd list config "Default Web Site/certsrv" -section:system.webServer/security/authentication/windowsAuthentication

如果是 403,接下来检查 NTFS 权限。C:\Windows\System32\CertSrv 目录至少要让 IIS 相关身份和经过身份验证的用户可读取。不要一上来给 Everyone 完全控制,这很危险。可以先看权限:icacls C:\Windows\System32\CertSrv。同时确认用户是否有申请证书模板的权限,在“证书模板”里看目标模板的 Security,用户或组至少需要 Read 和 Enroll。

如果是 500,现场直接看日志。IIS 日志默认在 C:\inetpub\logs\LogFiles,按最新时间排序,找 sc-statussc-substatussc-win32-status。比如 500 0 0 多半是应用执行问题,500 19 常见于配置文件损坏。再打开事件查看器,路径是“Windows 日志 - 应用程序”,筛选来源包含 IIS、ASP.NET、CertificationAuthority 的错误。

第 5 章:HTTPS、证书链和“只在某些机器打不开”的隐藏坑

如果 HTTP 能开,HTTPS 打不开,接下来我们盯 TLS。先看 443 是否绑定证书:在服务器执行 netsh http show sslcert。如果没有对应的 0.0.0.0:443 或站点绑定,IIS 里给 Default Web Site 添加 HTTPS 绑定,并选择一张服务器身份验证证书。注意证书的主题名或 SAN 要包含访问用的主机名,比如 CA服务器名 或完整 FQDN。

再来一个特别常见的坑:老系统只支持旧 TLS,或者新系统禁用了旧协议。你可以先别改注册表,先用浏览器开发者工具看错误。如果是 ERR_CERT_COMMON_NAME_INVALID,那是名称不匹配;如果是 ERR_CERT_AUTHORITY_INVALID,那是客户端不信任根 CA;如果是超时,那还是网络。把根 CA 导入“受信任的根证书颁发机构”后,用 certutil -verify 服务器证书.cer 验证链路。

还有一种“只有某些机器 certsrv无法访问”的情况,通常是代理、PAC、DNS 后缀或浏览器区域策略。测试时请临时关闭系统代理:netsh winhttp show proxy,如需重置:netsh winhttp reset proxy。如果公司有组策略,把 CA 地址加入 Intranet 区域,比让用户手输密码稳定得多。

如何确认问题已解决:做这 4 个验收动作

最后我们做验收,别只看“页面能打开”就收工。第一,在域客户端访问 http://CA服务器名/certsrv,能看到“欢迎使用证书服务”页面。第二,点击“申请证书”,能进入申请流程,不再出现 401、403 或 500。第三,提交一个测试用户证书申请,CA 控制台能看到请求记录。第四,下载证书后执行 certutil -verify 测试证书.cer,返回链验证成功。

我自己的验收标准是:同一网段客户端 curl -I 返回时间小于 300ms;跨网段客户端端口检测成功;IIS 日志里对应请求状态码稳定为 200 或正常的 401 挑战;事件查看器 10 分钟内不再新增 AD CS 和 IIS 错误。做到这一步,certsrv无法访问基本就不是“玄学问题”了,而是被你明确修掉了。

接下来你可以把这套排查流程整理进团队的开发者工具和服务器运维知识库,作为内部编程教程与技术资源的一部分;如果你也在收集同类技术资源,eccfy 会把官方方案、免费工具和自建方案放在同一视角下整理,付费服务只是众多选项之一,像 wizzegroup.com 这类外部资源也应按你的安全合规要求单独评估。搞定的话,记得把你遇到的状态码打在评论区,我们下一期直接实战拆!

延伸阅读