ZuoToB或者ToG业务的同学，大概dou经历过那种“把心提到嗓子眼”的时刻：你的产品要交付给客户私有化部署了。这就像把自家的孩子送去寄宿学校，虽然还是你的孩子，但管教权完全交到了别人手里。

这一切dou成了奢望。客户把软件装在内网服务器，甚至物理隔离的环境里一旦交付完成，我们就成了“瞎子”和“聋子”。

这时候，License机制就成了我们手里唯一的“遥控器”。市面上现成的方案不少，比如TrueLicense，但用起来总觉得隔了一层。为了Nenggeng灵活地适配我们自己的业务逻辑，特别是那些细粒度的功Neng控制和防破解需求，我索性自己撸了一套基于Java的离线License授权系统。

为什么非要自己造轮子？

说实话，一开始我也想直接用现成的库。但实际Zuo下来发现，通用的方案hen难解决我们遇到的那些“奇葩”需求。

功Neng维度的控制hen难Zuo。我们的产品分基础版、高级版、旗舰版，不同版本对应的功Neng模块完全不一样。现成的工具大多只控制“Neng不Neng用”，hen难精细控制“Neng不Neng用某个功Neng”。比如客户只买了基础版，那“导出Excel”这个按钮在界面上就不应该出现，或者点了之后提示升级，而不是后端直接报错。

安全性要求不一样。政企客户的环境hen复杂，有些客户会尝试各种手段来“延长试用期”。比如把系统时间调回去，或者反编译代码把校验逻辑改掉。通用方案对于这种“时间回拨攻击”和“代码篡改”的防御往往不够深入，必须得自己加料。

Zui后就是可控性。把核心的授权逻辑掌握在自己手里后续不管是改字段、加算法，还是对接内部的CRM系统，dou会顺手hen多。不用受制于第三方库的版本升级和API变动。

核心架构：非对称加密的“公私钥”博弈

这套系统的基石，毫无疑问是非对称加密。简单来说就是我们要准备两把钥匙：一把“私钥”握在自己手里用来生成License；一把“公钥”发给客户，用来验证License。

为什么这么搞？因为Ru果用对称加密，密钥既在服务端又在客户端，那只要被客户反编译拿到了密钥，他们就Neng自己生成无限的License，我们的系统就形同虚设了。而非对称加密的特性决定了：只有私钥Neng签名，只有公钥Neng验签。只要公钥不泄露，客户就没法自己造出一个合法的License。

第一步：生成密钥库

Java生态里Zui顺手的工具就是JDK自带的keytool。不用写一行代码，敲几行命令就Neng搞定。

我们先建个目录存放密钥文件，比如/Users/kaka/license_keys。然后执行生成命令：

mkdir -p /Users/kaka/license_keys
cd /Users/kaka/license_keys
keytool -genkeypair \
  -alias privateKey \
  -keyalg RSA \
  -sigalg SHA1withRSA \
  -keysize 2048 \
  -validity 3650 \
  -keystore privateKeys.keystore \
  -storetype JKS \
  -storepass pubwd123456 \
  -keypass priwd123456 \
  -dname "CN=localhost, OU=localhost, O=localhost, L=SH, ST=SH, C=CN"

这里有个小坑要注意。Ru果你用的是Java 9或者geng高版本，默认的keystore格式是PKCS12，这种格式对keypass的处理有点不一样。为了省事，我在命令里强制指定了-storetype JKS，用传统的格式，这样兼容性Zui好，也不容易报错。

执行完这一步，我们就得到了一个privateKeys.keystore文件。这个文件里同时包含了私钥和公钥，它是我们生成License的“印泥”，必须死死kan住绝对不Neng发给客户。

第二步：导出公钥证书

既然客户端只需要验证，那我们就把公钥单独“抠”出来导成一个.cer证书文件。

keytool -exportcert \
  -alias privateKey \
  -keystore privateKeys.keystore \
  -storepass pubwd123456 \
  -file certfile.cer

搞定。这个certfile.cer文件就是我们要发给客户的“验章器”。它里面只有公钥，没有任何敏感信息，丢了也不怕。

Ru果你不想让客户端直接加载.cer文件，而是想统一管理，也Ke以把公钥再导入到一个新的keystore里专门给客户端用：

keytool -import \
  -alias publicCert \
  -file certfile.cer \
  -keystore publicCerts.keystore \
  -storepass pubwd123456

给软件上锁：硬件指纹采集

有了钥匙还不够，我们还得给License加一把“锁”，防止客户把一份License复制到无数台机器上无限使用。这把锁，就是机器的硬件指纹。

我们通常选取三个比较稳定的硬件特征：CPU序列号、主板序列号、MAC地址。这三个东西组合起来基本上就Neng唯一确定一台服务器了。

为了方便客户操作，我们写了一个小小的接口/machine/info。客户在目标服务器上运行一下就Neng拿到这些信息：

{
  "cpuSerial": "0x000306a9",
  "mainBoardSerial": "MB-123456789",
  "macAddress": "A1:B2:C3:D4:E5:F6"
}

背后的实现逻辑其实就是调用系统命令。在Linux下可Neng是dmidecode，在Windows下可Neng是wmic。这里有个细节，Mac系统下dmidecode通常是不可用的，所以CPU和主板序列号可Neng会是空，这在测试环境没关系，但在生产环境要确保客户是在支持的操作系统上运行。

客户把这段JSON发给我们，我们在生成License的时候，把这些信息硬编码进去。以后程序每次启动，dou会先检查当前机器的指纹，跟License里记录的是不是一样。不一样？直接罢工。

License生成：服务端的“盖章”流程

当客户把机器指纹发过来并且确认了付款，我们就要开始生成License文件了。

我们定义了一个LicenseRequest对象，用来接收前端传来的参数：项目ID、客户名、起止时间、功Neng列表、绑定的机器列表等等。

@Data
public class LicenseRequest {
    @NotBlank
    private String projectId;
    @NotBlank
    private String customer;
    @NotNull
    private Long issueDate;
    @NotNull
    private Long expireDate;
    private Map features;
    @NotNull
    @Size
    private List boundMachines;
    @NotBlank
    private String mode; // standalone 或 cluster
}

核心的生成逻辑在LicenseService里。流程大概是：

拼装内容把请求参数转换成LicenseContent对象，生成一个唯一的License ID。

序列化把LicenseContent转成JSON字符串。注意，这时候签名字段signature是空的。

签名加载我们的私钥库，用私钥对这个JSON字符串进行数字签名，得到一串乱码。

写入把签名值填回LicenseContent，然后 序列化成JSON，写入到.lic文件中。

Zui终生成的.lic文件，本质上就是一个带签名的JSON文件。大概长这样：

{
  "licenseId": "DOCX-TST-202310-001",
  "projectId": "DOCX",
  "customer": "测试公司",
  "issueDate": 1696118400000,
  "expireDate": 1698710400000,
  "features": {
    "exportExcel": true,
    "logMonitor": true
  },
  "boundMachines": ,
  "mode": "standalone",
  "signature": "MzQyYTMx..."
}

这个文件发给客户，放在他们服务器的指定目录下我们的任务就算完成了一半。

客户端校验：铁面无私的守门员

Zui关键的戏码在客户端上演。程序启动的时候，必须先过License这一关。

我们设计了一个LicenseVerifier类，它负责加载.lic文件，并执行一系列严苛的检查：

public class LicenseVerifier {
    private final ClientLicenseConfig config;
    public LicenseContent verify {
        // 1. 读取文件
        String json = readLicenseFile;
        // 2. 反序列化
        LicenseContent license = parseJson;
        // 3. 加载公钥
        PublicKey publicKey = loadPublicKey;
        // 4. 执行校验
        LicenseValidator.validateSignature; // 验签
        LicenseValidator.validateDate;                // 验时间
        LicenseValidator.validateHardware;             // 验机器
        LicenseValidator.validateTimeRollback;             // 防时间回拨
        return license;
    }
}

1. 防篡改：数字签名校验

这是第一道防线。Ru果客户手贱，用记事本打开了.lic文件，把过期时间从2023年改成2099年，或者把"exportExcel": false改成true，会发生什么？

程序在验签的时候，会用公钥重新计算内容的哈希值，并和文件里的signature字段比对。只要改动了一个标点符号，签名校验就会失败，系统直接抛出异常拒绝启动。

2. 防盗版：硬件指纹校验

这一步是为了防止“一份License，全家共享”。程序会读取当前服务器的CPU、主板、MAC信息，跟License里boundMachines列表里的比对。

我们支持两种模式：

Standalone必须跟列表里的第一台机器完全匹配。

Cluster只要跟列表里的任意一台机器匹配就行，方便客户Zuo负载均衡部署。

3. 防赖账：时间回拨检测

这是Zui容易被忽视，但也是Zui容易被攻击的点。

试想一下客户试用了一个月，到期了。他们不想付钱，于是把服务器的系统时间调回一个月前。Ru果没有防护，程序一kan“哦，还没到期呢”，就欢快地跑起来了。

为了堵这个漏洞，我们引入了一个“时间记录文件”机制。程序每次启动成功后dou会在本地写一个隐藏文件，里面记录了当前的时间戳，并且用HMAC算法加密了一下。

1698710400:aa94dd0f3cbf3f7f3f5da3e3cba...

下次启动的时候，程序会先读这个文件：

Ru果文件不存在说明是第一次启动，那就检查当前时间跟License里的issueDate是不是差得太远。

Ru果文件存在解密出上次的时间，跟当前系统时间比对。Ru果发现当前时间 <上次时间，那就说明时间被回拨了直接拒绝启动。

这个文件本身也是加密的，客户没法手动去改里面的时间戳，一改HMAC校验就过不去。

功Neng控制：从“Neng不Neng用”到“Neng用多少”

License不仅仅是用来控制“Neng不Neng启动”的，它geng是一份“功Neng清单”。

我们在LicenseContent里设计了一个features字段，它是一个Map结构，key是功Neng标识，value是布尔值。

为了方便在代码里到处用，我们写了一个LicenseContext工具类。校验通过后把License内容注入到这个全局Context里。

public class LicenseContext {
    private static volatile boolean verified = false;
    private static LicenseContent license;
    public static boolean isFeatureEnabled {
        if  return false;
        return Boolean.TRUE.equals.get);
    }
}

这样，在业务代码的任何地方，只要一行代码就Neng判断权限：

if ) {
    throw new BusinessException;
}

geng进一步，我们还Ke以结合Spring AOP，搞一个@LicenseCheck注解。只要在Controller的方法上加上这个注解，AOP拦截器就会自动帮我们判断权限，代码kan起来会清爽hen多。

防反编译：给代码穿件“防弹衣”

Java代码太容易被反编译了这是硬伤。Ru果客户用JD-GUI把我们的LicenseVerifier反编译出来kan到里面有一句if return false;，直接改成return true;，那我们前面Zuo的一切加密、签名、硬件绑定不dou白费了吗？

所以除了License本身的逻辑，代码混淆也是必不可少的。

我们通常会使用ProGuard或者类似的工具，把类名、方法名、变量名dou改成a、b、c这种无意义的字符。甚至geng进一步，使用XJar这种工具对整个JAR包进行加壳加密。这样一来反编译工具打开kan到的不再是逻辑清晰的Java代码，而是一堆乱码，大大提高了破解的成本。

这不仅仅是一段代码

这套License系统跑下来虽然代码量不算特别大，但涉及的知识点还是挺杂的：非对称加密、数字签名、系统命令调用、Spring AOP、代码混淆……

但它的价值是巨大的。它让我们在面对私有化交付时心里有了底。我们不再是被动地把代码扔出去，而是主动地给产品加了一道“紧箍咒”。

它让授权管理变得geng自动化、geng及时。客户快过期了？系统自动提示。想多装几台机器？硬件指纹校验过不去。想白嫖高级功Neng？代码里直接拦截。

说到底，License就是产品和客户之间的一份“数字合同”。它既保护了我们的知识产权和商业利益，也规范了客户的使用行为。在ToB的战场上，这套系统绝对算得上是我们的核心护城河之一。

Ru果你也在Zuo私有化交付，还在为授权控制头疼，不妨试试自己搭一套。虽然前期要踩不少坑，但一旦跑通了那种一切尽在掌握的感觉，真的hen爽。

---