PKI CSR 格式与 certificate vs license（下篇）

CSR 内容是 Base64 吗

CSR（PEM 格式）里的内容确实是 Base64 编码的，但：

它 Base64 解码后得到的是 DER 二进制 ASN.1 结构，而不是 JSON、文本、明文数据。

CyberChef 的 "From Base64" 只是解码成原始二进制，你看到的输出是乱码是正常现象。

CSR 的 PEM → Base64 → DER 三层结构

CSR 文件（PEM）：

-----BEGIN CERTIFICATE REQUEST-----
MIIBSTCB7wIBADA...
-----END CERTIFICATE REQUEST-----

里面的 Base64 实际对应 DER (ASN.1 数据结构) → 二进制。

你可以这样理解：

PEM = Base64(DER)

CyberChef 正确解析 CSR 的方法

在 CyberChef 里：

1. 第一步：From Base64
2. 第二步：Parse ASN.1 Structure

例如流程：

From Base64 → Parse ASN.1

你就能看到人类可读的结构化内容。

OpenSSL 标准方式

openssl req -in your.csr -noout -text

你会看到：

• Subject
• SAN
• Public Key
• Signature Algorithm
• Signature

这是唯一正确的查看方式。

公钥为什么显示成 04:58:9a:9c 这样的 hex

常见的 OpenSSL 输出：

Pub:    04:58:9a:9c:c7:8c:af:6a:9e:a4:bd:d6:d1:db:5b:06:
       48:08:ac:34:51:4d:54:c5:6f:6b:e9:b1:62:0d:7c:e3:
       4e:d7:ab:15:48:9d:29:eb:4d:ca:1d:34:d6:a3:54:cd:
       13:f8:ea:33:cc:4d:a4:2b:05:a4:c7:27:03:9e:8a:2b:
       d5

为什么不是字符串

看到的公钥是：

• 椭圆曲线点坐标（二进制）
• 被 OpenSSL 以十六进制 Hex Dump 形式打印

不是字符串，因为公钥本来就是一段「数学数据」，不可读，不是字符编码，原始形式是 byte[]（原始二进制）。

为什么是这种格式

你使用的是 ECDSA / EC 密钥（椭圆曲线密钥）。

椭圆曲线公钥格式固定为：

0x04 || X 坐标 || Y 坐标

• 0x04 表示"非压缩公钥"
• 后面是 X、Y 坐标，每个约 32 bytes（取决于曲线，P-256 就是 32+32）

为什么 OpenSSL 用十六进制显示？

OpenSSL 默认把二进制数据以 hexdump 格式打印，更方便人类阅读。但这些都是二进制字节的十六进制表示，不是字符串。

字符串形式：PEM

如果想看"字符串形式的公钥"，应该用 PEM 格式：

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQ...
-----END PUBLIC KEY-----

但这里的 PEM 本质上仍然是 Base64(ASN.1) 的文本包装。里面真正的内容仍然是二进制结构（DER）。

用 hex 校验曲线

openssl ec -in key.pem -pubout -text

或：

openssl req -in your.csr -noout -text

它会显示同样的十六进制点坐标。

为什么 OpenSSL 输出 CyberChef 不识别

常见误解：OpenSSL 输出的 `04:58:9a:9c:...` 怎么用 CyberChef "From Hexdump" 没输出？

原因不是 CyberChef 的 bug，而是格式不匹配。

OpenSSL 输出不是"hexdump 格式"

OpenSSL 打印的 `04:58:9a:9c:...` 是：

• 十六进制 bytes（hex bytes）
• 不是 hexdump 格式

CyberChef 的 "From Hexdump" 需要的是类似 Linux hexdump 命令那样的格式：

00000000  04 58 9a 9c c7 8c ...
00000010  48 08 ac 34 51 4d ...

而 OpenSSL 打印的是简单的：

04:58:9a:9c:...

这不符合 CyberChef 的预期格式，所以会无法解析 → 输出为空。

正确的做法

方法 1：把 : 换成空格，再用 "From Hexdump"

04 58 9a 9c c7 8c af 6a 9e a4 bd d6 d1 db 5b 06 48 08 ac...

然后 CyberChef 用 From Hexdump 或 From Hex 都能解码出二进制。

方法 2：直接用 "From Hex"

最干净：CyberChef "From Hex" 不需要地址偏移与 ASCII 后缀。

CSR 的 Requested Extensions 字段

OpenSSL 解析 CSR 时常看到：

Requested Extensions:
    subjectKeyIdentifier:
        (unsuported extension)
    1.3.6.1.4.1.13159.1.2.509.3.1.1: critical
        (unsuported extension)
    1.3.6.1.4.1.13159.1.2.509.3.2.1: critical
        (unsuported extension)

Requested Extensions 是什么

CSR 里可以指定扩展字段，例如：

• subjectAltName
• basicConstraints
• keyUsage
• extendedKeyUsage

这些会出现在 CA 签发的证书中。但 `1.3.6.1.4.1.13159.*` 这种不是标准扩展。

为什么显示 unsupported

OpenSSL 不认识这些 OID 是什么意思，所以显示：

(unsupported extension)

并不表示 CSR 有问题，只表示：

• OpenSSL 的本地 OID 表里没有对应的名称和格式描述

CSR 仍然是合法的，CA 也可以处理。

OID 是什么

观察结构：

1.3.6.1.4.1.xxxxx

这是典型的 Private Enterprise Number (PEN)——某个公司申请的私有 OID 命名空间。

其中的 13159 是某家公司向 IANA 申请的企业编号。意味着这是该公司自定义的 PKI 扩展字段，行业标准不会包含。

可去 IANA PEN 数据库查：https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

为什么标记为 critical

如果 CA 不理解这个扩展，它必须拒绝该 CSR；必须写进证书，不能忽略。这通常出现在专用系统（HSM、智能卡、政府认证设备）生成的 CSR 中。

正常公共 CA（DigiCert、GlobalSign、Let's Encrypt）不会处理这些扩展。企业内部 PKI 或国密系统里可能很关键。

certificate vs license

很多人把 license 和 certificate 混在一起，但二者用途完全不同。

一句话结论：

• Certificate（证书）是「用来证明身份和公钥的密码学凭证」
• License（许可证 / 授权）是「允许你使用某个产品或功能的法律 / 商业授权」

Certificate（证书）

本质：一个由 CA 签名的、带有公钥的身份凭证。解决问题：

• 你是谁？
• 这个公钥是谁的？
• 我能不能信任你？

核心：密码学信任。常见使用：HTTPS / TLS、客户端认证（mTLS）、代码签名、设备身份认证、VPN、S/MIME。

License（许可证 / 授权）

本质：对"使用权"的授权声明，不是身份凭证。解决问题：

• 你是否有权使用这个软件 / 功能？
• 可以用到什么程度？
• 用多久？

核心：法律 + 商业授权。常见使用：商业软件授权（Oracle、VMware、Autodesk）、SaaS 付费许可、设备功能解锁、操作系统激活。

核心区别对照

为什么一起出现

在很多商业系统里：

• certificate 用来做"身份认证"
• license 用来做"功能授权"

典型：企业 VPN 设备用证书确认合法设备 / 用户，用 license 限制并发数。它们是配合关系，不是替代关系。

工程师版类比

certificate = 你是谁
license = 你能干什么

下篇准则

1. PEM = Base64(DER)——PEM 是文本，DER 是二进制结构。
2. CyberChef "From Base64 → Parse ASN.1"——最干净查看 CSR 内部结构的方式。
3. OpenSSL 的 hex 输出 ≠ CyberChef 的 hexdump——把 : 换空格即可。
4. 公钥不是字符串——它是数学点坐标（X, Y）的二进制形式。
5. CSR Requested Extensions 中的 unsupported——OpenSSL 不认识，不是 CSR 错。
6. certificate ≠ license——身份 vs 授权。