nukkitx服务器过期或不信任的根源，是Java环境的根证书库没有收录服务端使用的SSL证书签发机构；解决办法是按顺序检查系统时间、更新Java证书库，或者直接手动导入证书，三步之内就能搞定。
nukkitx服务器报“过期”或“不信任”时的真实场景
先别急着删服务端重装,这问题九成九和你的服务端文件本身没关系，我见过太多群友一看到控制台刷红字，就把整个nukkitx文件夹删了重新下，结果折腾一晚上还是老样子，其实这类报错最常出现在两个地方：一个是启动时，控制台直接抛异常，连开服流程都走不完；另一个是玩家连接时，客户端反复提示“无法验证服务器身份”或“连接不安全”，即使输入的是正确的内网IP也没用。
这两种情况其实是同一个病根TLS/SSL握手阶段，本地系统不认nukkitx服务端的证书，nukkitx本身使用了较新的安全协议版本，而你的Java环境或者操作系统的证书信任库，压根没收录签发票据的那家CA机构，加上部分伙伴用的是从网上随便下的整合包，里面的Java版本老得掉渣，证书库还停留在五六年前的出厂状态，过期和不信任就成了一对形影不离的难兄难弟。
先分清你遇到的是哪种“过期”
很多人把“证书过期”和“证书不受信”混为一谈，实际上处理方式完全不同。
- 证书过期：报错信息里通常带着
expired或者ValidFrom这类单词，本质是CA签发的有效期限到了，服务端需要去申请一张新证书，这在个人玩家自建的nukkitx服务器里不太常见，因为默认的自签名证书有效期极短，多见于用免费CA签发的三个月短期证书，老玩家常说的“nukkitx服务器过期怎么办”，多半追问的就是这一种。 - 证书不受信：报错信息里带着
not trust、untrusted或者PKIX path building failed，这是最普遍的，意思是你的Java信任库不认签发者，这跟时间无关，哪怕你的证书刚签出来一分钟，只要信任库里没有对应CA，照样报错。
nukkitx服务器证书不信任的三大根因
行业共识认为,nukkitx服务器证书不信任的成因虽然看着复杂，但往源头捋，无非卡在这三个地方。
Java运行环境太旧
nukkitx官方对Java版本有硬性要求,一般来说Java 8以上才能跑得动，但Java 8的早期小版本自带的cacerts文件格外贫瘠，这些年新成立的CA机构发了不少根证书，旧版Java根本没收录，你可以做一个简单的自检：打开命令行，输入java -version看看具体版本号，如果末尾是8u201或更早，那基本可以断定是它引发的“不信任”连锁反应。
系统时间与真实时间脱节
证书的“有效期”概念完全建立在时间轴上，如果服务器主板电池没电，或者你手动把系统时间调到了去年，那任何证书都会被认为是两个极端要么“尚未生效”，要么“已经过期”，这一条常在折腾黑苹果或老旧笔记本的用户里出现，排查成本最低，却最容易被忽略。
Nginx或面板类工具的中途干扰
这里要格外提一嘴,很多人的nukkitx并非直接暴露公网，而是套了一层Nginx反代，或者用MCSManager等面板做了端口映射，玩家连接时看到的证书是反代工具提供的，而不是nukkitx自己生成的，如果Nginx的SSL配置里指向的证书文件路径写错、权限不够，报错信息同样会伪装成“服务端证书不可信”，这属于部署层面的坑，需要单独排查。
完整实操：nukkitx服务器过期怎么办，步骤按顺序来
下面这份操作顺序是我自己踩过好几回坑之后总结出来的,效率最高，务必按顺序执行，别跳步，很多弯路就是跳步跳出来的。
第一步：校准服务器系统时间
这一步最省事,一分钟就能排除一个常见变量，Windows系统直接右键任务栏时间，选择“调整日期和时间”，打开“自动设置时间”开关，如果是Linux服务器，依次执行：
sudo timedatectl set-ntp true sudo timedatectl status
看到System clock synchronized: yes这行，就代表时间已经对齐，确认完时间后，先重启一次nukkitx，看报错是否消失，如果依然报错，问题就跟时间无关，直接进入下一步。
第二步：检查Java版本并决定是否升级
用命令行执行java -version，确认一下小版本号，如果版本低于8u202，或者主力Java是JRE 7，不用犹豫，直接去Adoptium官网下载新一代的OpenJDK，这里的数据可以参考Adoptium社区披露的信息，近年来的长期支持版本集中在
Java 8、Java 11和Java 17三条线上，nukkitx官方推荐的Java 11，在兼容性和新证书收录之间取得了不错的平衡。
下载后记得配置环境变量,别装完了却还在调用旧路径，配置完成后，再次执行java -version，确认显示的是新版本号，随后重启nukkitx服务端。
第三步：手动导入缺失的CA证书
如果升级完Java版本还是报“不信任”，那就要来硬的了手动把签发证书的CA根证书塞进Java的信任库，这里以最常用的ISRG Root X1为例（Let’s Encrypt签发的证书都挂在它名下）。
用浏览器进入https://letsencrypt.org/certs/isrgrootx1.pem，把页面上的内容复制保存为一个root.pem文件，然后打开命令行，定位到你的Java安装路径，执行以下命令：
keytool -import -trustcacerts -alias isrgrootx1 -file root.pem -keystore lib/security/cacerts -storepass changeit
这里changeit是Java信任库的默认密码，如果你之前改过，按自己的来，看到提示Trust this certificate? [no]:，输入yes回车，导入完成后，重启nukkitx，问题到此应该画上句号。
一条旁路：绕过证书验证的启动参数
如果你是单机自己玩,纯粹被这个报错卡住进不去，不想动证书库，那还有一个土办法，在nukkitx的启动脚本里，给Java虚拟机加上这几个参数：
-Dnukkitx.bypassCertificateCheck=true -Dcom.mojang.api.bypass.trust=true
请如实说清楚,这个方案只适合离线单机或完全内网环境，因为它相当于把安全验证直接关闭了，公网服务器千万别这么干，它属于救急偏方，不解决根本问题。
如何彻底预防：一劳永逸的证书维护习惯
解决完眼前的问题,下一个痛点自然浮现：玩个游戏而已，凭什么要隔三差五被证书折磨一回？做到下面三点，折磨自然会远离你。
把Java信任库更新固化到日常维护里
业内专家指出，绝大多数被证书坑到的服务器，根源都是环境常年不更新，Windows用户优先选择带“自动更新”功能的发行版JDK，Linux用户则可以通过包管理器定期执行全量升级，让证书库跟着系统小版本走，远比每次手动去抠CA文件来得安心。
拉起端口需要锁定具体端口
分享一个容易出错的细节,前面提到nukkitx默认使用19132端口，但很多伙伴在路由器或安全组里只放行了TCP协议，而基岩版联机用的是UDP协议，若只放行TCP，连接时的表现就是间歇性超时，界面提示莫名像“服务器身份不信任”，建议在防火墙规则里同时允许TCP和UDP的19132端口，别让网络层的问题伪装成证书问题。
做好服务器快照再动证书操作
在修改cacerts文件之前，顺手做一次服务端目录的完全备份，或者打一个系统快照，如果误删了信任库里的某个根证书，导致全部插件失灵，恢复起来只需要回滚一次快照，这能让你在折腾的时候心里更有底。
Q&A：两张复述高频故障的找补方案
nukkitx服务器报“PKIX path building failed”后直接闪退怎么办
闪退说明异常没有被启动脚本捕获,属于致命错误，这次反馈出现在主线程的敏感阶段，先确认启动脚本里是否有-Xms和-Xmx参数，如果这两个参数设置值太小，会在证书验证阶段触发内存溢出，顺带以“不信任”的伪装推锅给证书，建议将-Xmx至少设为2G，随后再依照上文顺序排查时间与信任库，两者结合才能让问题真正落地。
玩家端提示“无法验证服务器身份”，但服务端控制台没有任何报错，这是谁的问题
这是典型的客户端缓存问题，与服务端无关，玩家的设备曾经用旧证书连接过这个地址，系统将这个证书指纹记在缓存里，服务端更换新证书后，客户端发现指纹对不上，就生硬地抛出不信任的警示，解决办法是让玩家进入游戏设置，找到存储管理，清空该服务器的缓存数据，或者直接移除服务器列表后重新添加，连接成功后，新指纹会被正常记录。
用面板启动的nukkitx，导入证书时报“权限不足”怎么办
报这个错,说明面板进程权限比Java运行时低，Linux系统中，面板的用户组通常没有对lib/security/cacerts的写权限，正确操作是先在独立终端中，用sudo完成证书导入，导入完成后将文件属主改为面板用户：chown 面板用户名:用户组 lib/security/cacerts，然后重启面板，属于面板的权限限制，而不是证书本身的问题。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/708043.html
