公网IP证书申请与部署指南：纯国内CA验证流程全记录

如果你的业务跑在一台只有公网IP的服务器上，没有域名，或者域名还在备案流程里，而客户和接口调用方又要求尽快把服务升级成HTTPS，那你大概率遇到过这个场景：自签证书导进去，Chrome照样红屏；买域名证书又签不到IP上；找国际CA申请公网IP证书，材料递上去之后验证环节迟迟没有下文。我上个月刚给一台上海机房的服务器办完一张公网IP证书，整个过程走的是纯国内验证：在线提交、人工审核、端口放校验文件、签发、部署，全程都在国内完成，最终把 https://IP 的证书告警彻底消掉了。这篇文章把我这次操作的全过程、配置命令和踩过的坑整理出来，给同样需要给IP地址签正规证书的人当参考。

1. 为什么公网IP证书比域名证书更“挑机构”

1.1 IP直连的业务场景一直没有消失

很多人觉得，互联网上访问服务都用域名，证书自然也只需要签域名。但实际跑到生产环境里会发现，IP直连的场景远比想象中多：企业之间接口对接，对方只给了你一个固定IP，没有配套域名；设备管理平台、视频监控、门禁网关，设备端根本不支持域名解析；测试环境、预发布环境临时用IP顶上；还有一些内部系统从安全角度的确不允许暴露域名信息，直接走IP。我在这次项目中处理的就是一个供应链管理平台的API网关，对方要求必须用正规CA签发的证书，不能自签，否则他们风控一关就过不去。

域名证书不能用在IP上的原因很简单：证书签发的核心逻辑是“验证申请人拥有这个地址的所有权”，域名可以靠DNS解析来证明，而IP地址没有DNS，CA需要一套独立的验证机制，IPC之外还要确认你对IP的实际控制权。所以公网IP证书本质上是一种特殊的SSL证书，它的常用名称（CN）和 SAN 条目里放的是IP地址而不是域名。证书行业把这类证书叫“IP证书”或者“IP SAN证书”，它和域名证书一样，可以由受信任的CA签发，让浏览器正常信任，只是签发的条件和验证路径完全不同。

1.2 浏览器对IP证书的信任基线

可能是被早期各种滥用吓怕了，主流浏览器对IP证书的信任要求卡得很严格。按照CA/Browser Forum的基线要求，CA要签发IP证书，必须做到几件事：申请者必须向CA证明自己对该公网IP地址的控制权；证书里必须包含IP地址的subjectAltName（SAN）条目，且SAN里的IP必须和申请验证的一致；证书有效期最长只能到398天；CA不得给保留IP、内网IP、多播地址这类非公网IP签发证书。

这些都意味着，想靠自签证书躲掉浏览器报警是行不通的，因为浏览器判断的是“这张证书是否由受信任的根证书签发”，而不是“证书里的IP对不对”。哪怕你把自签证书的CN和SAN都写成IP，只要根证书不在系统信任列表里，Chrome和Edge依然会给出“您的连接不是私密连接”的红色拦截页。只有CA签发的IP证书，才能让现代浏览器把IP访问当成一个合法站点来对待。

1.3 纯国内验证到底是什么意思

“纯国内验证”这个说法，听起来有点云里雾里，其实落到操作层面就三点：

• CA的验证服务器在国内，校验端口时直接访问你的IP，不用经过跨境链路。
• 申请材料、人工复核、电话确认都在国内完成，语言和时区不存在障碍。
• 证书的受理、签发、售后都在国内机构，出问题可以直接找客服，不需要发英文工单来回磨。

这对部署在国内机房的服务器特别重要。如果CA的验证节点在境外，它需要能通过公网访问你的80或者443端口，才能完成文件校验或者HTTPS校验。而国内很多机房和云平台的网络策略对境外访问本身就不友好，申请过程中经常遇到验证服务器访问超时，提交了资料却卡在“等待验证”状态，最后只能反复重试。纯国内验证的申请，验证服务器在国内，访问国内IP的链路又近又稳，基本一次就能完成校验。我这次选择国内CA，很大程度上就是冲着这一点。

2. 申请前的门槛：材料、IP与选型

2.1 先确认你是不是“真有资格”签IP证书

不少人在申请环节被卡住，不是资料不对，而是前置条件没满足。公网IP证书的申请，CA会要求你证明对IP地址的控制权，所以有几件事必须提前确认。

• IP必须是固定公网IP。动态IP没法做证书绑定，CA验证通过后如果IP漂移，整张证书就废了。
• IP必须是公网地址。像192.168.x.x、10.x.x.x这类私网地址，任何正规CA都不会签。
• 80端口或443端口必须能被公网访问。CA会通过访问你的IP来放置校验文件或完成HTTPS校验，端口不通，验证必失败。
• 服务器必须已经绑定这个IP，并且你能控制服务器的网站根目录或进程。
• 如果是企业申请，营业执照、组织信息要和CA要求的一致；个人申请的话，部分国内CA也支持，但审核材料更多，周期也长一些。

我在准备阶段就遇到过一次教训：最初我打算用443端口做验证，结果发现那个端口被另一个服务占用了，验证服务器连不上，耽误了半天。后来先把端口理清楚，再提订单就顺利多了。所以申请前最好先画一张当前的端口占用和防火墙放行清单，别等CA来验证的时候才发现网络不通。

2.2 CA怎么选：国际CA和国内CA的差别

市面上支持IP证书的CA分两类：国际CA和国内CA。这里并非说国际CA不好，而是在“纯国内验证”这个需求下，两者的体验差别很大，把核心差异列在下面。

如果你是给国内云服务器上的IP申请证书，我建议直接选国内有电子认证服务资质的CA。不是说国际CA不行，而是“纯国内验证”这个诉求，本质上就是希望整个流程在国内闭环，国内CA天然占优势。而且真到了验证那天，如果CA的验证服务器访问不了你的IP，你还能打电话催一下，让技术支持帮忙看日志，比发英文邮件来回解释要舒服太多。

2.3 申请前必须先把IP“钉死”

IP证书和域名证书最大的不同在于，它和IP地址是强绑定关系。证书一旦签发，证书里的IP SAN就是那个具体地址，你不能像域名一样加一条A记录解析到新服务器就算完事。所以提交申请之前，一定要确认下面几个问题：

• 这个IP是弹性公网IP还是普通公网IP？如果是后者，服务器回收后IP就被释放了，证书作废。
• 后续一年内有没有迁移机房的计划？迁移意味着IP变更，证书要重新申请。
• 有没有可能给这IP做NAT转发到别的后端？如果你用NAT映射，证书验证时CA访问的是映射后的地址，你需要保证验证状态下映射是高可用的，不要一边申请证书一边调整网络拓扑。

把这些确认好，再去生成CSR。否则证书签下来了，结果第二天IP换了，钱和时间全白费。

3. 走一遍国内验证流程：从CSR到签发

3.1 生成CSR时把IP写对

CSR（证书签名请求）是申请证书的第一步，很多人在这里就踩坑。IP证书的CSR里，CN字段必须填写IP地址，而不是域名，同时SAN里也要带上IP。建议使用OpenSSL结合配置文件生成，这样最稳妥。

先用一行命令生成私钥和CSR：

bash复制openssl req -new -newkey rsa:2048 -nodes -keyout ip.key -out ip.csr -subj "/C=CN/ST=Shanghai/L=Shanghai/O=YourCompanyName/CN=1.2.3.4"

注意把 1.2.3.4 换成你自己的公网IP。这里 CN 是IP，O 是组织名称，如果你是个人申请，组织字段可以写你的姓名或按CA要求填。

如果证书需要同时绑定多个IP（比如一台服务器有IPv4和IPv6地址，或者你有两个公网IP），用一行命令就不够了，需要写一个OpenSSL配置文件：

ini复制[ req ]
distinguished_name = dn
req_extensions = v3_req
prompt = no

[ dn ]
C = CN
ST = Shanghai
L = Shanghai
O = YourCompanyName
CN = 1.2.3.4

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
IP.1 = 1.2.3.4
IP.2 = 2408:8207:xxxx:xxxx::1

然后执行：

bash复制openssl req -new -key ip.key -out ip.csr -config ip_csr.cnf

生成完CSR后，可以用下面的命令检查SAN是否正确：

bash复制openssl req -text -noout -in ip.csr | grep -A 1 "Subject Alternative Name"

这一步必须确认输出里有 IP Address:1.2.3.4 这样的内容，如果只有域名没有IP，CA那边很可能直接拒收。

3.2 三种验证方式，优先端口文件验证

把CSR提交给CA之后，会进入验证环节。国内CA一般提供三种验证方式，我实际体验下来，最推荐的是端口文件验证。

第一种是HTTP端口文件验证。CA会给你一个随机生成的验证文件，比如 9C8B2A6F1E.txt，让你放到网站的根目录下，CA通过访问 http://你的IP/9C8B2A6F1E.txt 来确认你对IP的控制权。这种方式最简单，也最不容易出错。

放置验证文件前，先创建一个目录并放好文件：

bash复制mkdir -p /var/www/ip_verify
echo "9C8B2A6F1E7D4C3B" > /var/www/ip_verify/9C8B2A6F1E.txt

然后在Nginx里专门为这个验证请求建一个location规则：

nginx复制server {
    listen 80;
    server_name _;

    location = /9C8B2A6F1E.txt {
        alias /var/www/ip_verify/9C8B2A6F1E.txt;
    }

    location / {
        root /var/www/html;
        index index.html;
    }
}

这样其他请求正常走站点，只有验证文件请求会被精确匹配。配置完成后，先用一台电脑或者手机4G网络访问一次：

bash复制curl -I http://你的IP/9C8B2A6F1E.txt

如果返回200，说明外部已经能访问到文件，可以通知CA开始验证了。

第二种是HTTPS端口验证。如果你443端口跑着HTTPS服务，可以把验证文件放到HTTPS服务的相应目录下，CA会通过 https://你的IP/验证文件 访问。这种方式的好处是443端口更稳定，不容易被运营商屏蔽，但前提是你的HTTPS服务本身配置正确，否则也会失败。

第三种是邮箱和电话人工复核。国内CA在自动校验后通常还会做一道人工审核：向企业注册邮箱发一封确认邮件，点击链接确认申请；部分地区或订单可能还会有人工电话回访，问一些基础信息比如“申请证书的IP是多少”“用来部署什么服务”。这个过程一般不会问太复杂的东西，但电话务必保持畅通，尤其是填写的联系人手机号。

3.3 验证文件放好之后，等结果的日子干什么

提交验证后，不是干等着就行。我这次在文件校验通过后，还做了一件事：把服务器的443端口证书临时换成一张自签证书，并要求CA用HTTPS方式二次复核。虽然国内CA一般只做一次文件校验就够了，但多一道确认能降低后续被风控驳回的概率。

等待期间，建议做几件互不干扰的事：

• 把证书密钥备份好，私钥一旦丢失，签下来的证书没法补回同样的一份。
• 检查一下服务器时间是否准确。证书对时间敏感，如果服务器时间偏移太大，部署HTTPS后浏览器照样报错。
• 提前写好Nginx或者Java、Apache的配置片段，做到证书一下来就能直接粘贴部署。
• 如果申请的是OV级IP证书，顺便准备一份营业执照扫描件和授权书，有些CA在人工审核时会临时要求补材料。

国内CA的签发速度通常不错，材料齐全的情况下，快的当天或者次日就能收到证书包，慢一点也不会超过3个工作日。如果超过5个工作日还没动静，不要傻等，直接联系客服催办，问清楚是卡在验证还是卡在审核。

3.4 拿到证书包，先做一次自检

证书签发后，CA一般会给你一个压缩包，里面包含服务器证书、根证书和中间证书。不要直接扔到服务器上就完事，先在本机做一次自检。

先用证书包里的服务器证书和你的私钥测试匹配度：

bash复制openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in ip.key | openssl md5

两条命令输出的MD5值必须一致，不一致就说明证书和私钥不匹配，需要检查是不是下载错文件了。

然后检查证书里的IP是否和你申请的一致：

bash复制openssl x509 -noout -text -in server.crt | grep -A 1 "Subject Alternative Name"

确认输出里包含 IP Address:你的IP，且没有多余的错误IP，就可以进入部署环节了。

4. 把IP证书部署到服务端：Nginx和它的朋友们

4.1 Nginx 配置示例

如果你的服务用的是Nginx，配置IP证书和配置域名证书几乎没有区别，唯一要注意的是 server_name 要写IP地址或者用 _ 兜底。下面是一个最小可用的HTTPS配置：

nginx复制server {
    listen 443 ssl;
    server_name 1.2.3.4;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/ip.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里把HTTP请求重定向到HTTPS，避免用户访问 http://IP 时出现明文连接：

nginx复制server {
    listen 80;
    server_name 1.2.3.4;
    return 301 https://$host$request_uri;
}

配置完成后，先测试配置语法再重载：

bash复制nginx -t
systemctl reload nginx

然后打开浏览器直接访问 https://1.2.3.4，正常情况下地址栏会直接出现小锁标志，不再有安全告警。

4.2 证书链拼接和自检命令

CA给的压缩包里通常会有多个pem文件，直接配置 server.crt 可能会报“证书不完整”，因为缺少中间证书。通用做法是把服务器证书和中间证书拼成一个fullchain文件：

bash复制cat server.crt intermediate.crt > fullchain.pem

注意拼接顺序是“服务器证书在前，中间证书在后”，别把根证书也拼进去。拼接完用下面命令验证整条链是否完整：

bash复制openssl verify -CAfile root.crt -untrusted intermediate.crt fullchain.pem

如果输出里有 OK 字样，说明证书链没有问题。最后用OpenSSL模拟一次SSL握手，看看实际部署的效果：

bash复制echo | openssl s_client -connect 1.2.3.4:443 -servername 1.2.3.4 2>/dev/null | openssl x509 -noout -subject -dates

这里能看到证书的subject和有效期，也能确认服务器是否真正启用了证书。

4.3 Spring Boot、Apache、IIS简要说明

不是所有人都用Nginx，我这次部署完Nginx之后，又帮同事在一个Java服务上装了一样的证书，这里把其他几种常见中间件的配置要点一并列出来。

Spring Boot 2.x以上可以直接配置PEM证书：

properties复制server.port=8443
server.ssl.enabled=true
server.ssl.certificate=file:/etc/nginx/ssl/fullchain.pem
server.ssl.certificate-private-key=file:/etc/nginx/ssl/ip.key
server.ssl.key-store-password=

Apache的话，配置在虚拟主机文件里：

apache复制<VirtualHost *:443>
    ServerName 1.2.3.4
    SSLEngine on
    SSLCertificateFile    /etc/apache2/ssl/server.crt
    SSLCertificateKeyFile /etc/apache2/ssl/ip.key
    SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt
</VirtualHost>

IIS相对麻烦一些，需要把证书包转成 .pfx 格式，然后导入到本地计算机的“个人”证书存储，再在“网站绑定”里选择HTTPS类型，主机名填IP地址，指定证书后重启IIS。转换PFX可以用OpenSSL：

bash复制openssl pkcs12 -export -out server.pfx -inkey ip.key -in server.crt -certfile intermediate.crt

导出时会要求设置一个密码，这个密码后面导入IIS时要用到，别随手一设就忘了。

5. 实测中高频踩坑点实录

5.1 验证文件总被默认站点“吃掉”

这个坑在Nginx多站点环境下特别常见。服务器上跑了三四个虚拟主机，你新建了一个专门放验证文件的server块，但访问 http://IP/验证文件.txt 时，请求却没有落到这个块上，而是被第一个server块接管了，返回404。原因在于Nginx匹配server_name时，如果用IP直接访问，必须显式匹配到 server_name 1.2.3.4 或 server_name _ 的server块，否则会落到默认server。

解决方法是确认验证文件所在的server块设置了 listen 80 default_server;，并且只有这一个80端口默认站。我建议在验证期间，把其他80端口的server块暂时注释掉或者改成非default，验证完成后再恢复。配置里加一行 default_server 就能把优先级锁死：

nginx复制server {
    listen 80 default_server;
    server_name _;
    location = /9C8B2A6F1E.txt {
        alias /var/www/ip_verify/9C8B2A6F1E.txt;
    }
}

5.2 安全组和防火墙把验证服务器挡在外面

这个问题几乎每个申请IP证书的人都会撞上。本地 curl http://IP/验证文件.txt 能通，因为你是在服务器本机请求的；但CA验证服务器从公网来访问时，请求会被云平台的安全组或者服务器本机防火墙拦掉，导致验证超时。

所以验证前一定要做一次“模拟公网访问”，方法是找一台不在同一内网的电脑，用流量或者另一台云主机执行：

bash复制curl -I http://你的IP/验证文件.txt

如果返回超时或者连接拒绝，优先检查三条链路：云控制台安全组是否放行了入方向80端口；服务器本机是否开启了firewalld或ufw；如果有硬件防火墙或者CDN前置，是否拦截了非浏览器请求。我这次就被安全组坑了一次，当时只放行了443端口，验证走80端口时一直失败，最后在云平台加了一条入方向规则才放行。

放行命令参考：

bash复制firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload

如果你是Ubuntu的ufw：

bash复制ufw allow 80/tcp

5.3 IP证书和IP地址是强绑定的

这一点再多强调一次都不为过。IP证书签下来之后，你只要换IP，证书就彻底没用了，只能重新走一遍流程。我们这次特别小心翼翼，甚至在证书申请期内就冻结了服务器网络变更，避免平台自动续费失败导致公网IP被释放。对于用动态IP或者PPPoE拨号上网的场景，我的建议是直接放弃申请IP证书，老老实实用域名加DDNS，否则证书钱大概率打水漂。

另外，证书有效期现在是398天，意味着每年都要重新申请一次。建议在证书到期前30天设置提醒，或者在运维监控里把证书过期时间作为一个告警指标。这样提前发现问题，不要在证书到期当天被客户投诉了才想起来。

5.4 老浏览器和客户端不认IP证书

虽然现代主流浏览器都支持IP SAN证书，但仍然有部分老旧的浏览器、操作系统或者移动端Webview组件，对IP证书的兼容性做得不好。如果你需要对公网提供大范围访问，而且用户群体里有大量老设备，一定要在部署后做一轮客户端兼容性测试，至少测Chrome、Edge、Safari、Android原生浏览器、微信内置浏览器这几种场景。如果出现“证书不受信任”的情况，那不是证书的问题，而是客户端发起的证书链校验逻辑过旧。这种场景下是没办法通过改证书解决的，只能升级客户端，或者改成域名访问。

可以用在线SSL检测工具或者OpenSSL命令检查证书链是否完整、证书是否过期，确认问题到底出在哪一层。不要自己先慌了神，更不要直接换成自签证书，那样只会让更多的客户端报警。

5.5 关于IP地址使用范围和业务用途的经验

最后说点经验层面的东西。在申请公网IP证书前，一定要把IP地址的使用范围搞清楚：这个IP上跑的服务是给内部用的，还是给外部客户用的？如果只是内部用，IP证书不是必须的，自签证书加白名单反而更灵活；如果要给外部客户用，尤其对方有安全审计团队，正规CA签发的IP证书基本就是硬要求。

另外，虽然公网IP证书本身的验证流程和域名备案关系不大，但服务器如果部署在境内机房，对外提供Web服务的IP地址，建议提前确认当前网络服务是否已按本地要求完成相关登记手续，不要等到验证环节才发现这层问题被卡住。纯国内验证的CA通常对国内用户的实名和资质信息要求更严格，材料越规范，签发越快。

我在操作中还发现一个有价值的小技巧：申请证书时的联系人邮箱和电话，务必填写能够随时响应的，不要填写离职员工或者已经停用的邮箱。CA在人工复核阶段给这个邮箱发确认链接时，如果无人点击，整个订单可能会在系统里滞留，直到你主动催促。这次我特意留了项目组的公共邮箱，并设置了邮件提醒，复核邮件发出来10分钟内就点掉了，整个过程走得非常顺。

如果你也在给一台只有公网IP、没有域名的服务器发愁HTTPS证书，按照上面的流程走一遍，大概率能少踩一半的坑。把这篇文章存下来，等你真正申请的时候再翻一翻，尤其是验证文件那个环节，提前把Nginx配好，能省下大半天等待时间。