证书掉了能自签救急：长期用坑不少

自签证书这玩意儿，说白了就是自己给自己盖个章——证书是真的，章也是真的，但盖章的人不在浏览器信任的那份名单里。所以「证书掉了能自签救急」这句话我只认一半：救急行，长期挂着就是给自己挖坑。真到了证书过期、私钥弄丢、上线前半小时发现 HTTPS 打不开的时候，自签确实能把服务先拉起来，让访问先跑通，不至于整站一片红字。但很多人签完之后就懒得换了，后面那些麻烦，全是从这一步开始的。

证书掉了能自签救急，先分清它救的是哪一段

掉证书这事其实就那么几种：到期忘了续、证书链没拼全、私钥丢了、迁移服务器的时候文件漏拷。前两种用正规证书还能修，后两种基本只能重签。自签能补上的是「有证书、能加密」这一段，补不上的是「别人凭什么信你」这一段。这两段搞混了，就会出现那种情况：站点自己打开一切正常，外部用户全是警告页，然后你怀疑是配置写错了，改了半天 Nginx 也没用。

还有一种更隐蔽的：证书文件在，配置也指对了，但中间证书没带上。浏览器有时候能靠缓存或者 AIA 自己去拉，看着没事，换个客户端就崩。这种时候自签反而会把问题盖住，因为你换上去之后「能连上了」，就以为修好了。

十分钟顶上去，命令就那几条

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 30 -subj “/CN=example.com”，一条命令出一对文件。这里 -days 千万别手滑写成 3650，写 30 到 90 就行，逼着自己记得到期。Nginx 里 ssl_certificate 指 cert.pem，ssl_certificate_key 指 key.pem，然后 reload。要是前面还有一层 CDN 或者反代，注意别把这张自签证书传到最外层给用户看，内部链路用它、对外那一层还是得正规证书，这个顺序弄反了比不签还难受。

浏览器那一关，配置再对也过不去

自签不在公共信任库里，Chrome、Safari、Edge 一定报警，这不是你配置的问题，是机制就这样。更麻烦的是开了 HSTS 的站点，警告页连「继续访问」都不给点，用户直接被挡在门外。你自己电脑上装个根证书、点个例外，十秒钟解决，但外部用户不会为了看你一个页面去折腾系统设置。所以那种「我这边能打开啊」的反馈，参考价值基本为零。

接口和小程序那边，比浏览器更不讲情面

网页能打开、接口全挂，这是自签最常见的翻车方式。curl 默认就拒，得加 -k 或者把 cert.pem 塞进 –cacert；Java、Python 那些 HTTP 客户端默认校验；小程序和 App 的请求域名要过平台那一关；支付、短信、物流的回调，人家更不会为你的自签证书开绿灯。这些链路平时没人盯着，等业务侧反馈「下单失败」才发现，排查方向还容易跑偏到代码上。

长期用自签，坑主要在人和流程

正规证书有一套签发、续期、吊销的流程，到期前会有人给你发邮件。自签什么都没有，全靠自觉。私钥散在几个人的电脑上，换人交接的时候找不到当初那条命令，证书文件随手命名成 cert.pem、cert2.pem、cert_new.pem，半年后自己都分不清哪个在用。这类问题不会当天爆，一般在你最忙的时候爆。

还有个隐性成本，叫信任

用户看到警告页，多数人的反应是直接关掉，不会去点「高级」再点「继续」。做内容站、做电商，这一步基本等于自断流量。至于搜索引擎怎么处理自签站点，各家口径不完全一样，别拿它去赌长期访问，具体以搜索引擎官方文档和服务商页面说明为准。

那什么场景自签是合理的

内网系统、测试环境、localhost 调试、反代到后端的那一段内部链路、离线设备、还没拿到域名的开发阶段——这些都挺合适。判断标准其实就一条：访问的人是不是自己人，能不能接受那个警告。能接受，自签就是省事；不能接受，自签就是给自己找活干。

换回正规证书时，顺手把这几点做掉

私钥单独备份一份，别跟证书文件放同一个目录；证书链按「服务器证书 → 中间证书」的顺序拼，顺序反了部分客户端会报错；上自动续期，再加一个到期监控，双保险；把生产目录里那几张自签的 pem 清掉，免得哪天被误加载，出了问题还以为证书没换。

自签是创可贴，不是愈合。先止血，把服务拉起来，然后尽快换正规证书。真要说有什么经验，那就是把到期日写进监控和日历里——这比记住任何一条命令都实在。