REDISANT 提供互联网与物联网开发测试套件 #

互联网与中间件：

工业与物联网：

本文以轻松的笔触介绍了 HTTPS 证书背后的数据结构和格式，只要稍有计算机科学知识并对数字证书略知一二就不难理解。

HTTPS 证书是一种文件，与任何其他文件一样。它的具体格式是由 RFC 5280 规定的，该标准采用了一门名为 ASN.1 的语言，专门用于定义文件格式，也可以说是定义数据结构。譬如，C 语言是这样定义数据结构的：

struct point {
  int x, y;
  char label[10];
};

Go 语言则是这样定义的：

type point struct {
  x, y int
  label string
}

而写成 ASN.1 就会是这样：

Point ::= SEQUENCE {
  x INTEGER,
  y INTEGER,
  label UTF8String
}

与 Go 和 C 的语法相比，ASN.1 的优势在于它不依赖某一门特定的编程语言，任何语言都可以根据上述 ASN.1 定义实现 Point 结构。不仅如此，借助工具还可以将 ASN.1 定义自动转换成你想使用的语言。在 ASN.1 中，一系列相关的定义称为一个“模块”。

ASN.1 的另一特点在于它有各种序列化格式，也就是说数据可以从内存导出成一串字节（或存入文件中），也可以由一串字节反过来导入内存。因此任何一台设备生成的证书其他设备都能正常读取，无需顾忌 CPU 和操作系统的差异。

还有一些语言也能起到与 ASN.1 同样的作用。例如，Protocol Buffers 也提供了一门定义类型的语言，以及负责将各类对象编码的序列化格式。 Thrift 同样具备类似的语言和序列化格式。 Protocol Buffers 和 Thrift 完全可以胜任定义 HTTPS 证书的职责，只不过 ASN.1 早在 1984 年就已诞生，对于数字证书（1988 年）和 HTTPS（1994 年）技术来说具备先天优势。

多年来 ASN.1 标准几经修订，各修订版本通常以发布年份加以区分。本文介绍 ASN.1 旨在帮助读者准确理解 RFC 5280 及其他 HTTPS 证书相关标准，所以我们将着重探讨 1988 年版，并简要提及后续版本引入的功能。各版本的标准文档可以直接在国际电信联盟（ITU）的网站上下载，不过部分文件只对 ITU 成员开放。相关标准包括 X.680（定义了 ASN.1 语言）和 X.690（定义了 DER 和 BER 序列化格式），其前身分别是 X.208 与 X.209。

ASN.1 最主要的序列化格式称为 Distinguished Encoding Rules (DER)。它是对 Basic Encoding Rules (BER) 格式加以严格规范化而成的一种变体。例如，在 DER 格式中，即使是集合类型（SET OF）的元素也必须有序排列。

DER 格式的证书通常会进一步转换成 PEM 格式，这一过程采用 Base64 编码将二进制字节转化为一连串的字母、数字、“+”和“/”符号，并在头尾加入“-----BEGIN CERTIFICATE-----”与“-----END CERTIFICATE-----”两行文字以示分隔。 PEM 格式的优点在于方便复制与粘贴。

本文将首先介绍 ASN.1 使用的类型与语法，然后再介绍 ASN.1 定义的对象是如何编码的。读者不妨随时翻阅前后章节，毕竟 ASN.1 语言的部分功能直接决定了其编码方式。本文倾向使用更为通行的术语，如用“字节”而非“八位组”，用“数值”而非“内容”。 “序列化”与“编码”则作为同义词使用。

类型

INTEGER

就是老生常谈的整数。可以是正数，也可以是负数。 ASN.1 的 INTEGER 类型最为特别之处在于大小不限。 int64 不够大？小事一桩。这对于表示 RSA 模数之类远超 int64 范围的整数（比如 22048）尤为有用。严格说来 DER 格式的整数范围是有上限的，但上限极高：任何 DER 字段的长度必须能够用 126 个字节来表示。因此，DER 能表示的最大的 INTEGER 数值是 256(2**1008)−1。真正无限大的 INTEGER 必须用 BER 编码，因为 BER 对字段长度没有限制。

字符串

ASN.1 有很多字符串类型：BMPString、GeneralString、GraphicString、IA5String、ISO646String、NumericString、PrintableString、TeletexString、T61String、UniversalString、UTF8String、VideotexString，还有 VisibleString。对于 HTTPS 证书来说基本只需要关心 PrintableString、UTF8String 和 IA5String。 ASN.1 模块定义字段的时候也会定义其应当使用的字符串类型。例如：

CPSuri ::= IA5String

PrintableString 只能存储 ASCII 中的部分字符，包括字母、数字、空格以及一些特定的符号：' () + , - . / : = ?。注意其中不包括 * 和 @。虽然允许使用的字符有限，但在存储空间上并无优势。

某些字段，例如 RFC 5280 中的 DirectoryString，有多种字符串类型可供选择。由于 DER 编码会将字符串的类型信息一并存储，使用 PrintableString 这类字符串时务必确保其内容符合类型要求。

IA5String 源自 International Alphabet No. 5，限制较为宽松，所有 ASCII 字符几乎都能使用，在证书中常用于邮箱地址、DNS 域名、网址之类的字段。需要注意的是 IA5 编码中有部分数值的含义与 US-ASCII 并不相同。

TeletexString、BMPString 和 UniversalString 对 HTTPS 证书来说都已过时，建议不再使用。但一些历史悠久的证书可能在其过时之前就已颁布，因此还能发现它们的身影，需要予以解析。

与 C 和 C++ 语言中的字符串不同，ASN.1 的字符串不以空字符结尾。事实上，字符串中出现空字符也是完全符合规范的。如果两套系统采取不同方式读取同一 ASN.1 字符串，就可能出现安全漏洞。例如，过去攻击者只要持有 evil.com 域名，就能诱使某些证书颁发机构为“example.com\0.evil.com”颁发证书。当时的证书验证软件会认为这一证书对 example.com 也是有效的。在 C 和 C++ 中处理 ASN.1 字符串必须加倍小心，避免产生安全漏洞。

日期和时间

时间类型也有不少：UTCTime、GeneralizedTime、DATE、TIME-OF-DAY、DATE-TIME 以及 DURATION。但在 HTTPS 证书中只需关心 UTCTime 和 GeneralizedTime。

UTCTime 采用 YYMMDDhhmm[ss] 的格式表示日期和时间，末尾还可以加上时区，或者加上“Z”表示协调世界时（UTC）。例如，UTCTime 的 820102120000Z 和 820102070000-0500 表示同一时刻：1982 年 1 月 2 日纽约（UTC−5）的早晨七点，即协调世界时的正午十二点。

因为 UTCTime 没有写明是 20 世纪还是 21 世纪，RFC 5280 补充规定了其范围是 1950 至 2050 年。 RFC 5280 还规定时区必须为“Z”，且秒数不能省略。

GeneralizedTime 用四位数字表示年份，从而得以支持 2050 年以后的日期。它还允许秒数出现小数（而且句点和逗号竟然都可以作为小数点）。 RFC 5280 又禁止了秒数出现小数，并要求时区为“Z”。

OBJECT IDENTIFIER

Object identifier (OID) 是一种全球唯一的层状标识符，由一串整数组成。它可以用来标识任何东西，但通常用于指代标准、算法、证书扩展、组织机构或政策文件。例如 1.2.840.113549 表示的是 RSA 安全公司，因此该公司有权分配以这一串数字开头的 OID，比如 RFC 8017 定义的 1.2.840.113549.1.1.11 表示 sha256WithRSAEncryption。

类似地，1.3.6.1.4.1.11129 指的是 Google 公司，Google 则在 RFC 6962 中将 1.3.6.1.4.1.11129.2.4.2 分配给了证书透明化系统中的 SCT 列表扩展，因为该系统最初便是由 Google 研发的。

同一前缀下的所有 OID 在英文中又称为 OID arc。 OID 越短，占据的空间就越小，价值也就越高，对于大量使用 OID 的格式尤为如此。 OID 前缀 2.5 分配给了 Directory Services，指的是一系列的标准文档，在 HTTPS 证书中处于核心地位的 X.509 标准也位列其中。证书中有很多字段用的都是这个简短的前缀。例如，2.5.4.6 表示国家名称（countryName），2.5.4.10 则表示机构名称（organizationName）。这些 OID 在绝大多数证书中至少都会出现一次，自然越短越好。

标准文件中的 OID 常用英文词汇表示以便阅读，有时还会拼接形成新的 OID。以 RFC 8017 为例：

   pkcs-1    OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
   }
   ...

   sha256WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 11 }

NULL

NULL 就是 NULL，懂了吧？

SEQUENCE 和 SEQUENCE OF

别被名字给骗了，这是两种截然不同的类型。 SEQUENCE 相当于大多数编程语言中的 struct 类型，用于存放若干不同类型的固定字段。参见下文的证书示例。

SEQUENCE OF 表示的则是任意数量同一类型的字段，相当于编程语言中的数组或列表。例如：

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

可以是 0 个、1 个乃至 7000 个 RelativeDistinguishedName，并且按某种特定顺序排列。

不过 SEQUENCE 和 SEQUENCE OF 还是有相似之处的：二者的编码完全相同！这一点留到探讨编码时再详细介绍。

SET 和 SET OF

这两种类型与 SEQUENCE 和 SEQUENCE OF 基本相同，只是强调其中元素的顺序无关紧要。但是在编码前必须先予以排序。例如：

RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndValue

注意：本例使用了 SIZE 关键字要求 RelativeDistinguishedName 中至少应有一个元素，但通常 SET 和 SET OF 都可以为空。

BIT STRING 和 OCTET STRING

前者表示一段任意的二进制位，而后者表示一段任意的字节。这两种类型可以存放无特殊结构的数据，比如密码学中的 nonce 和散列值。它们也可以当作 C 语言中的 void 指针或 Go 语言中的空接口（interface{}）使用，表示数据虽然存在内部结构，但该结构只在别处定义，与 ASN.1 的类型系统无关。例如，证书的数字签名就是用 BIT STRING 定义的：

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

新版的 ASN.1 语言还支持详细规定 BIT STRING 的内容，OCTET STRING 亦然。

CHOICE 和 ANY

CHOICE 表示可以使用其定义中列出的任意一种类型。例如，下方的 Time 要么是 UTCTime，要么是 GeneralizedTime：

Time ::= CHOICE {
     utcTime        UTCTime,
     generalTime    GeneralizedTime }

ANY 表示允许使用任意类型。但实际中通常还有一些 ASN.1 语法难以表达的限制。例如：

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY -- DEFINED BY AttributeType

ANY 在协议的扩展机制中扮演了重要的角色。它为将来新增字段留出了余地，协议的主体规范发布后不必反复修订，新字段只需注册新的类型（用 OID 表示），并随之定义具体的字段格式即可。

需要注意的是 ANY 属于 ASN.1 从 1988 年遗留下来的类型。 1994 年 ANY 就已经被废弃，取而代之的是 Information Object Class，这是一种规范化的扩展定义方式，弥补了 ANY 的不足。现如今这一改变已经相当彻底，2015 年版的 ASN.1 标准甚至连 ANY 的字样都没有出现。但是如果回过头看 1994 年版还是可以找到有关这一变动的探讨。此处介绍这种旧式语法是因为 RFC 5280 仍在使用， RFC 5912 则把 RFC 5280 及相关标准中的类型都转换成了 2002 年的 ASN.1 格式。

标签：定义,证书,ASN.1,SEQUENCE,轻松,RFC,格式,入门
From： https://www.cnblogs.com/cj94/p/18623849

ASN.1 轻松入门