记录一次 SharePoint 通过 IIS 配置 HTTPS 后无法访问的定位过程。
访问地址：
https://WIN-1NMHTJKVJBO/
一、问题现象
在 IIS 中使用“服务器证书 → 创建自签名证书”生成证书后，访问：
https://WIN-1NMHTJKVJBO/证书信息类似：
颁发给（Subject）：WIN-1NMHTJKVJBO.ms.test.com
颁发者（Issuer）：WIN-1NMHTJKVJBO.ms.test.com颁发者和颁发给相同是自签名证书的正常现象。IIS 管理器创建自签名证书时会根据服务器名称生成证书，不能在界面中直接修改 CN、Issuer 或 Subject。
二、通过 Edge CDP 查看实际错误
通过 Edge 的 CDP 端口 9222 查看页面，而不是只根据证书页面猜测错误。
1. 短主机名的错误
访问：
https://win-1nmhtjkvjbo/Edge 实际显示：
ERR_SSL_KEY_USAGE_INCOMPATIBLE这不是普通的“自签名证书不受信任”错误，而是证书的 Key Usage/EKU 不符合 HTTPS 服务端证书要求。常见要求包括：
- 增强型密钥用法（EKU）：
Server Authentication - OID：
1.3.6.1.5.5.7.3.1 - 密钥用法：
Digital Signature - RSA 证书通常还需要：
Key Encipherment
2. FQDN 的错误
尝试访问证书中的完整名称：
https://WIN-1NMHTJKVJBO.ms.test.com/Edge 实际显示：
DNS_PROBE_FINISHED_NXDOMAIN说明该完整域名没有 DNS 解析记录。此时请求尚未进入 TLS 握手和证书校验阶段，因此需要先解决 DNS/hosts 问题。
三、为什么 IIS 自签名证书不能直接修改 CN
IIS 的“创建自签名证书”功能比较简单：
- Subject/CN 通常根据当前服务器名称自动生成；
- 自签名证书由自己签发自己，因此 Subject 和 Issuer 相同；
- IIS 管理器没有编辑 CN、SAN、Issuer 的功能；
- 证书创建后不能直接修改字段，只能重新生成或申请新证书。
“证书友好名称”只是证书管理器中的显示名称，不会改变 CN、Issuer，也不会影响证书的实际身份校验。
四、修复方案
方案 A：使用 IIS 自签名证书对应的完整域名
如果使用 IIS 生成的证书，应访问证书中的名称：
https://WIN-1NMHTJKVJBO.ms.test.com/但客户端必须能将该域名解析到 SharePoint/IIS 服务器 IP。
正式环境：配置 DNS A 记录
在内部 DNS 的 ms.test.com 区域添加：
WIN-1NMHTJKVJBO.ms.test.com A <SharePoint/IIS服务器IP>客户端验证：
nslookup WIN-1NMHTJKVJBO.ms.test.com或：
Resolve-DnsName WIN-1NMHTJKVJBO.ms.test.com临时测试：修改 hosts
在每台访问客户端的以下文件中，以管理员身份添加：
C:\Windows\System32\drivers\etc\hosts内容示例：
192.168.1.100 WIN-1NMHTJKVJBO.ms.test.com然后刷新 DNS 缓存：
ipconfig /flushdnsDNS 解决的是“域名找到服务器”，不会解决证书信任问题。自签名证书还需要导入访问客户端的“受信任的根证书颁发机构”。
方案 B：使用 PowerShell 生成自定义自签名服务器证书
如果必须支持短主机名和完整域名，可以在服务器上用管理员 PowerShell 重新生成，并显式指定 SAN 和服务器身份验证用途：
New-SelfSignedCertificate `
-Type SSLServerAuthentication `
-DnsName "win-1nmhtjkvjbo","WIN-1NMHTJKVJBO.ms.test.com" `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "SharePoint HTTPS - WIN-1NMHTJKVJBO" `
-KeyAlgorithm RSA `
-KeyLength 2048 `
-HashAlgorithm SHA256 `
-NotAfter (Get-Date).AddYears(3)检查证书：
Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.FriendlyName -eq "SharePoint HTTPS - WIN-1NMHTJKVJBO"} |
Format-List Subject,Issuer,EnhancedKeyUsageList,NotAfter,Thumbprint在证书详细信息中确认“使用者备用名称”（SAN）至少包含：
DNS=win-1nmhtjkvjbo
DNS=WIN-1NMHTJKVJBO.ms.test.com然后在 IIS 中打开：
站点 → 目标 SharePoint 网站 → 绑定 → https → 编辑 → SSL 证书选择新证书。
方案 C：使用内部 CA，正式环境推荐
如果环境中有 AD CS 或其他内部 CA，建议申请服务器证书，而不是长期使用 IIS 简单自签名证书。证书应包含：
SAN:
win-1nmhtjkvjbo
WIN-1NMHTJKVJBO.ms.test.com
EKU:
Server Authentication此时证书形式通常为：
颁发给：WIN-1NMHTJKVJBO
颁发者：公司内部 CA只要客户端信任内部 CA，通常不需要逐台客户端手动信任服务器证书。
五、最终验证清单
nslookup或Resolve-DnsName能解析实际访问的域名；- IIS 站点绑定类型为
https，端口为443； - IIS HTTPS 绑定选择了正确证书；
- 证书 SAN 包含浏览器地址栏中的主机名；
- EKU 包含
Server Authentication； - 自签名证书或内部 CA 已被客户端信任；
- 必要时检查 SSL 绑定：
netsh http show sslcert六、结果
后来更换为 Exchange 生成的证书后访问恢复正常。由此确认，原 IIS 自签名证书的问题重点在于其服务端证书用途/扩展配置不适合当前 HTTPS 场景；同时，使用 FQDN 访问时还必须配置 DNS 或 hosts。Exchange 证书通常带有更适合 IIS HTTPS 的 Server Authentication EKU 和 Key Usage，因此替换后可以正常完成 TLS 握手。
注意：证书字段中的“公用名（CN）”不能替代 SAN。现代浏览器主要根据 SAN 校验主机名，生成或申请证书时应显式配置 SAN。