Powershell之New-SelfSignedCertificate实战：从基础命令到内网HTTPS服务部署

1. New-SelfSignedCertificate基础入门

第一次接触自签名证书时，我也被各种专业术语搞得晕头转向。简单来说，New-SelfSignedCertificate就是Windows系统自带的一个PowerShell命令，它能快速生成用于测试的自签名证书。想象一下，这就像你自己给自己开了一张身份证，虽然不能在银行使用，但在家里验证身份完全够用。

在局域网环境中部署HTTPS服务时，这个命令特别实用。比如开发团队需要测试一个内部使用的Web应用，或者运维需要快速搭建临时API接口，使用New-SelfSignedCertificate可以省去申请正式证书的繁琐流程。我去年就遇到过这种情况：客户临时要求演示一个HTTPS服务，从申请证书到审批至少需要3天，而用这个命令3分钟就搞定了。

先来看最基本的命令格式：

powershell复制New-SelfSignedCertificate -DnsName "test.example.com" -CertStoreLocation "cert:\LocalMachine\My"

这个命令会在本地计算机的"个人"证书存储区生成一个证书。这里的-DnsName参数特别重要，它指定了证书适用的域名，如果写错了会导致浏览器警告。我曾经就犯过这个错误，把example.com写成exmaple.com，结果所有同事访问时都看到红色警告页面，被笑话了好几天。

2. 实战：生成企业级自签名证书

2.1 高级参数配置

在实际工作中，简单的测试证书往往不能满足需求。我们需要更专业的配置。比如这个命令：

powershell复制New-SelfSignedCertificate -DnsName "internal.company.com", "*.dev.company.com" -CertStoreLocation "cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddYears(2) -FriendlyName "Internal Dev Certificate"

这个命令做了几件重要的事情：

• 支持多个域名和通配符子域名
• 使用更安全的RSA 2048位加密
• 采用SHA256哈希算法
• 设置2年有效期
• 添加了易于识别的友好名称

我曾经为一个电商项目配置过类似证书，当时团队需要同时支持api.shop.com和admin.shop.com两个域名。使用通配符证书可以大大简化配置，而且比申请多个单域名证书更经济。

2.2 证书存储位置详解

CertStoreLocation参数决定了证书的存储位置，常见的有：

• cert:\CurrentUser\My：当前用户的个人证书
• cert:\LocalMachine\My：本地计算机的个人证书
• cert:\LocalMachine\Root：受信任的根证书颁发机构

选择存储位置时需要考虑使用场景。如果是个人开发测试，用当前用户存储就够了；如果是服务器应用，一定要用本地计算机存储。我有次在IIS上部署时忘了这茬，结果服务启动总是报错，排查了半天才发现证书存错位置了。

3. 证书管理与验证

3.1 使用MMC管理证书

生成证书后，可以用Windows自带的MMC控制台来管理。操作步骤：

1. 按Win+R，输入mmc回车
2. 点击"文件"→"添加/删除管理单元"
3. 选择"证书"，点击"添加"
4. 选择"计算机账户"，然后"完成"

在"个人→证书"下就能看到生成的证书了。右键可以查看详细信息、导出或删除证书。记得第一次使用时，我被满屏的证书列表吓到了，后来才发现可以通过"友好名称"快速定位自己创建的证书。

3.2 常见问题排查

最常遇到的错误就是"拒绝访问"，这通常是因为：

1. 没有用管理员权限运行PowerShell
2. 尝试修改受保护的系统证书存储区
3. 账户权限不足

解决方法很简单：右键点击PowerShell图标，选择"以管理员身份运行"。如果还不行，检查是否尝试修改了Root等系统存储区。我团队的新人经常犯这个错误，现在我们都把"以管理员运行"写进了操作手册。

4. 部署到实际服务

4.1 IIS服务器配置

在IIS中绑定HTTPS证书的步骤：

1. 打开IIS管理器
2. 选择目标站点，点击"绑定"
3. 添加HTTPS绑定
4. 从下拉列表选择刚生成的证书
5. 设置主机名为证书中的DNS名称

关键点在于证书的"友好名称"要容易识别，否则在一长串证书列表中很难找到正确的。我们项目组现在都采用"环境_用途_日期"的命名规范，比如"Prod_WebAPI_202308"。

4.2 Nginx服务器配置

对于Nginx，需要先导出证书：

powershell复制$cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {$_.FriendlyName -eq "Internal Dev Certificate"}
Export-Certificate -Cert $cert -FilePath C:\certs\dev.crt
Export-PfxCertificate -Cert $cert -FilePath C:\certs\dev.pfx -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText)

然后在Nginx配置中添加：

nginx复制server {
    listen 443 ssl;
    server_name internal.company.com;
    ssl_certificate C:/certs/dev.crt;
    ssl_certificate_key C:/certs/dev.key;
    # 其他配置...
}

注意路径要用正斜杠，这是Nginx的要求。我第一次配置时用了反斜杠，结果Nginx启动直接报错，查了半天日志才发现问题。

5. 企业内网最佳实践

在内网环境中使用自签名证书，我总结了几个实用技巧：

1. 统一命名规范：比如"部门_服务_环境_日期"，方便管理
2. 集中存储证书：建立一个共享目录存放所有证书文件
3. 文档记录：记录每个证书的用途、有效期和负责人
4. 自动化续期：用PowerShell脚本定期检查证书有效期

我们团队现在用Jenkins自动执行证书检查任务，提前30天邮件通知负责人续期。这个系统上线后，再没出现过证书过期导致服务中断的事故。

对于大型企业，可以考虑搭建内部CA（证书颁发机构）。虽然配置复杂些，但能实现统一管理和自动信任。去年我们为金融客户部署了这套方案，管理员再也不用为每个服务单独生成证书了。