高加索 0.9.15

概述

高加索的目标是在不限制证书如何使用的情况下自动化证书颁发和续订。

例如，没有假设证书将用于保护HTTP，或者用于提供任何内容：您可能需要证书来验证用户，或签署您的邮件，或保护SQL服务器套接字。

不幸的是，caucase无法自动验证签名请求内容是否与某个服务（例如，检查HTTPS服务是否由有权使其提供特殊文件的人请求）相匹配。

这也意味着，尽管caucase对许多证书字段和扩展应用了RFC推荐的限制以确保值得信任，但它对主题和备用主题证书字段没有任何限制。

为了仍然允许使用证书，caucase使用自身来验证实施验证程序的用户（无论是人类还是其他）：他们告诉caucase要发出哪些证书。一旦完成，在待续期证书仍然有效（未过期、未吊销）的情况下，任何证书都可以在密钥持有人的简单请求下延长。

通过caucase自动在提交时签署一定数量的证书，系统启动（为caucased操作HTTPS创建第一个服务证书，以及创建第一个用户证书以控制进一步的证书颁发）。

词汇表

caucase操作以下非对称加密概念。

• 密钥对：一个私钥和相应的公钥。可以从私钥中导出公钥，但不能反过来。因此，私钥本身被认为是密钥对。

• 证书：证书是证书颁发机构对给定的公钥和一组属性属于授权实体的保证。简称cert或crt。证书按定义由CA签名。

• 证书颁发机构：一个任意可信（但其行动和决定值得信任）的条目，可以颁发证书。简称CA。

• 证书签名请求：一个实体产生的文件，表示他们希望获得认证，并将其发送给证书颁发机构。证书签名请求包含公钥和CA应该作出声明的期望属性集。CA有自由权颁发不同的属性集，或者不颁发证书。

• 证书吊销列表：列出由CA颁发但不再应受信任的证书。这可能发生有多种原因：私钥被泄露，或者其拥有实体不再应受信任（例如：实体访问受保护服务的权限被吊销）。

• PEM：一种常用于各种加密数据的序列化机制。它依赖于base64，因此是7位安全的（与DER不同），并且非常普遍受到支持。caucase独家使用PEM格式。

有效期

加密密钥在使用和老化过程中会磨损。

当然，它们在使用过程中不会生锈或变薄。但每次使用一个密钥，每次攻击者接触到公钥，私钥的某些比特就会不可避免地泄露，从而削弱了它。

因此，密钥必须定期更新以保持预期的安全级别。因此，每个证书都有有限的寿命，包括caucase发出的证书。

caucase发出的证书的单位持续时间是“正常”证书的有效期。默认为从证书签名之日起93天，或大约3个月。

然后CA证书的默认有效期为4个“正常”证书的有效期。由于CA更新在caucase中不需要x509级交叉签名（出于决定，为了避免依赖于证书提供方中间CA支持，而是依赖于更广泛的多CA证书支持在验证器方），因此CA证书无法可靠地更新，而不会对发出的“正常”证书的证书验证造成风险，其下限为3个有效期。CA证书更新由两个阶段组成

• 被动分发阶段：当前CA证书剩余寿命小于2个“正常”证书的有效期：生成新的CA证书并在需求时分发（在“正常”证书更新和颁发，使用caucase工具检索CRL...），但不用于签名任何内容。

• 活跃使用阶段：新的CA证书的有效期超过一个“正常”证书的生命周期。这意味着所有仍在活跃使用的现有证书自新的CA证书存在以来至少需要更新一次。这意味着所有证书持有人都有机会了解新的CA证书。因此，新的CA证书开始用于签署新的证书，而旧的CA证书则随着其签署的“正常”证书的过期而不再使用。

默认情况下，所有caucase工具在每次证书更新时都会生成一个新的私钥，与之前的私钥无关。

最后，还有一个有限的有效期，尽管原因不同：撤销证书的列表也有最大的生命周期。在caucase中，CRL在每次请求时都会重新生成，并且

• 没有以前的CRL

• 以前的CRL已过期

• 自上次CRL创建以来发生了任何撤销

以下是证书和CA证书更新过程的示意图

Time from first caucased start:
  +--------+--------+--------+--------+--------+--------+--------+-->
Certificate 1 validity:      |                 |                 |
  |[cert 1v1]  [cert 1v3]  [cert 1v5]  [cert 1v7]  [cert 1v9]  [ce...
  |      [cert 1v2]  [cert 1v4]  [cert 1v6]  [cert 1v8]  [cert 1vA]
Certificate 2 validity:      |                 |                 |
  |    [cert 2v1]  [cert 2v3]| [cert 2v5]  [cert 2v7]  [cert 2v9]|
  |          [cert 2v2]  [cert 2v4]  [cert 2v6]| [cert 2v8]  [cert...
CA certificates validity:    |                 |                 |
  [ca v1                     |        ]        |                 |
  |                 [ca v2   |                 |        ]        |
  |                          |        [ca v3   |                 |...
  |                          |                 |        [ca v4   |...
CRL validity for CA1:        |                 |                 |
  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][  ]        |                 |
CRL validity for CA2:        |                 |                 |
  |                 [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][  ]        |
CRL validity for CA3:        |                 |                 |
  |                          |        [ ][ ][ ][ ][ ][ ][ ][ ][ ][...
CA renewal phase:            |                 |                 |
  |none             |passive |active  |passive |active  |passive |...
Active CA:                   |                 |                 |
  [ca v1                    ][ca v2           ][ca v3            |...
Trust anchor:                |                 |                 |
  [ca v1                     |       ][ca v2   |       ][ca v3   |...

图例

+--------+ : One certificate validity period (default: 93 days)

关注点

• 本示意图假设没有发生撤销

• 通常同时有效2个CA证书

• 总共有2个同时有效的CRL，每个CA证书一个

• 由CA v2签署的第一个cert 1是cert 1v6

• 由CA v2签署的第一个cert 2是cert 1v5

命令

Caucase提供了一些命令来处理证书。

{
  "description": "Caucase backup header",
  "required": ["algorithm", "key_list"],
  "properties": {
    "cipher": {
      "description": "Symetric ciher used for payload",
      "required": ["name"],
      "properties": {
        "name":
          "enum": ["aes256_cbc_pkcs7_hmac_10M_sha256"],
          "type": "string"
        },
        "parameter": {
          "description": "Name-dependend clear cipher parameter (ex: IV)",
          "type": "string"
        }
      }
      "type": "object"
    },
    "key_list": {
      "description": "Content key, encrypted with public keys",
      "minItems": 1,
      "items": {
        "required": ["id", "cipher", "key"],
        "properties": {
          "id": {
            "description": "Hex-encoded sha1 hash of the public key",
            "type": "string"
          },
          "cipher": {
            "description": "Asymetric cipher used for symetric key",
            "required": ["name"],
            "properties": {
              "name": {
                "enum": ["rsa_oaep_sha1_mgf1_sha1"],
                "type": "string"
              }
            },
            "type": "object"
          }
          "key": {
            "description": "Hex-encoded encrypted concatenation of signing and symetric encryption keys",
            "type": "string"
          }
        },
        "type": "object"
      },
      "type": "array"
    }
  },
  "type": "object"
}

0.9.15 (2023-05-19)

• 修复对最近（至少>=40.0.2）加密版本的兼容支持

0.9.14 (2022-11-07)

• 清理：让更新的代码检查器更高兴。

• 在Python 2.7中显式依赖ipaddress模块。

• 减少对客户端/服务器时间差异的敏感度。

• 修复在PEM文件的目录中遇到损坏的符号链接时的崩溃。

0.9.13 (2021-12-22)

• 改善经常挂起的计算机上的行为。这应该可以避免错过证书更新截止日期。

• 修复对最近pyca.cryptography的测试支持，它已停止支持>28位的OID。这意味着现在没有使用128位UUID弧的CA的升级路径。

• 提高测试稳定性。

0.9.12 (2021-10-20)

• 修复本地信任锚CA到期后的caucase-updater崩溃。

0.9.11 (2021-10-07)

• 取消对安装时2to3的依赖以实现py3兼容性。现在源代码直接兼容2.7和3.x。

0.9.10 (2021-04-07)

• 正确处理当前但已过期的CA证书。

• 正确处理CA证书缺失的CRL。

• 添加caucase.client.CaucaseClient.close方法。

0.9.9 (2021-03-02)

• 在CRL中添加AuthorityKeyIdentifier扩展。

• 接受由非当前CA签署的用户证书。

• 根据其AuthorityKeyIdentifier keyid扩展而不是序列号命名CA证书。

• 为每个CA证书生成一个CRL，因为一些使用ssl的服务在没有由验证证书相同的CA签署的CRL时失败。

• 修复CA更新期间的信任锚分发：正确的信任锚是仍有效的最老的CA。

0.9.8 (2020-06-29)

• 添加对Python3的支持。

• 添加对每文件一个CA证书布局的支持。对于不支持从单个文件加载多个CA证书的服务。

• 修复caucase.sh认证使用（被0.9.4“使caucased https CA证书更安全”破坏）。

• 当caucase-updater认为需要更新但caucased没有提供新版本时，避免忙等待。

• 修复在较慢的机器上的测试超时。现在任何比树莓派1快的机器都应该通过。

0.9.7 (2020-06-04)

• 修复CRL更新：*教导caucased在其到期之前更新CRL。*使caucase-updater检查CRL到期日期。

• 在许可证中授予额外权限。

0.9.6 (2019-05-27)

• 不要使用128位OID弧作为caucase内部使用，因为它不受广泛支持。

• 各种CLI可用性改进。

0.9.5 (2019-01-24)

• 添加–version支持。

• 重新设计日志记录以减少冗余（特别是在测试中）。

• 修复caucased在更新其https证书时有时崩溃。

• 使caucased日志更像apache。

• 使caucased响应更符合标准（405响应中的“Allow”头和在所有响应中的“Date”头）。

• 修复对系统时区的无意依赖。

0.9.4 (2018-11-14)

• 改进文档。

• 尝试性网络友好性（尚未在现实生活中使用，因此实用性仍不确定）：*通过限制它可以签署的证书，使caucased https CA证书更安全地添加到信任存储（例如：浏览器）。*基于cookie的CORS访问控制，具有粗糙的用户界面。*API使用application/hal+json格式进行自我文档化。

• 尝试性Python3友好性，可能仍然存在文件IO编码问题。

0.9.3 (2018-09-21)

• 在caucased中添加对监听多个特定地址的支持。

• shell实现不再依赖于外部文件。

• 在用ssl上下文包装套接字之前不要在https端口上启动监听。

• 使caucase-updater可用于匿名服务（例如，它们只需要连接到caucase认证的服务，而无需使用caucase进行身份验证）。

• 为caucased sqlite数据库使用更严格的文件权限。

• 在用户代理头中包含caucase版本。

• 使caucased日志格式更像apache的默认格式。

• 修复caucased https证书更新。修复了每两个月发生一次的崩溃。

• 使caucase-updater在网络错误上重试。修复了暂时性网络错误上的崩溃。

0.9.2 (2017-11-03)

• 支持将现有的CA迁移到caucase：导入CA证书和CRL。

• 需要CRL签名检查（提高密码学模块版本要求）。

• 在CA证书中提供CRL分发点扩展。

• 更好地与http配合：* 捕获更多错误以提供良好的状态码 * 支持传输编码：分块 * 支持Expect: 100-continue

• 生成符合TLS的证书（域名必须在备用名称扩展中，主体不足以满足要求）。

• 降低测试速度要求。

• 添加“caucase”命令的shell实现。

• 证书续签绕过待处理的CSR限制。

• caucase-manage：用于离线数据库维护的新命令。

0.9.1 (2017-09-21)

• 文档改进

• 包装改进

0.9.0 (2017-08-02)

• 实现“caucase”的“cau”部分

• 大规模重构：删除flask依赖，删除HTML UI，重构REST API，重构CLI工具，重构WGSI应用程序，数据库不兼容的重设计。

0.1.4 (2017-07-21)

• caucase web参数“auto-sign-csr-amount”可用于设置必须自动签名的CSR数量。

0.1.3 (2017-06-30)

• 在cli中添加对备份caucase数据库的支持

• 序列号是从csr_id中获取的随机唯一格式化的十六进制数。

• 在签署证书时允许设置自定义主题（X509Name）。

• 添加新的cliweb命令，当需要时，将下载/更新caucase web的CRL文件。

0.1.2 (2017-05-12)

• cliweb：续签现在接受阈值选项以检查是否需要续签，并在证书续签后运行可选的on-renew脚本。

0.1.1 (2017-04-27)

• 证书授权机构的初始实现。