自签名

⚠️ SelfSigned 颁发者通常用于在本地引导 PKI，这是一个针对高级用户的复杂主题。要在生产环境中安全使用，运行 PKI 会引入围绕轮换、信任存储分发和灾难恢复的复杂规划要求。

如果您不打算运行自己的 PKI，请使用其他颁发者类型。

The SelfSigned 颁发者并不代表证书颁发机构本身，而是表示证书将使用给定的私钥“自签名”。换句话说，证书的私钥将用于签名证书本身。

此 颁发者 类型适用于引导自定义 PKI（公钥基础设施）的根证书，或用于为快速测试创建简单的临时证书。

有重要的注意事项——包括安全问题——需要考虑 SelfSigned 颁发者；一般来说，您可能希望使用 CA 颁发者而不是 SelfSigned 颁发者。也就是说，SelfSigned 颁发者对于最初引导 CA 颁发者非常有用。

注意：引用自签名证书的 CertificateRequest 必须还包含 cert-manager.io/private-key-secret-name 注释，因为与 CertificateRequest 对应的私钥需要用于签名证书。此注释由 Certificate 控制器自动添加。

部署

由于 SelfSigned 颁发者不依赖任何其他资源，因此配置起来最简单。仅 SelfSigned 节必须出现在颁发者规范中，不需要其他配置。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: sandbox
spec:
  selfSigned: {}

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-cluster-issuer
spec:
  selfSigned: {}

部署后，您应该能够立即看到颁发者已准备好进行签名。

$ kubectl get issuers  -n sandbox -o wide selfsigned-issuer
NAME                READY   STATUS                AGE
selfsigned-issuer   True                          2m

$ kubectl get clusterissuers -o wide selfsigned-cluster-issuer
NAME                        READY   STATUS   AGE
selfsigned-cluster-issuer   True             3m

引导 `CA` 颁发者

使用 SelfSigned 颁发者的理想用例之一是引导私有 PKI 的自定义根证书，包括使用 cert-manager CA 颁发者。

下面的 YAML 将创建一个 SelfSigned 颁发者，颁发根证书并使用该根证书作为 CA 颁发者。

apiVersion: v1
kind: Namespace
metadata:
  name: sandbox
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-selfsigned-ca
  namespace: sandbox
spec:
  isCA: true
  commonName: my-selfsigned-ca
  secretName: root-secret
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-ca-issuer
  namespace: sandbox
spec:
  ca:
    secretName: root-secret

或者，如果您希望使用 ClusterIssuer 在集群中的任何位置使用 SelfSigned Certificate CA 签名 Certificates，请使用下面的 YAML（对最后一步进行了轻微修改）。

apiVersion: v1
kind: Namespace
metadata:
  name: sandbox
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-selfsigned-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: my-selfsigned-ca
  secretName: root-secret
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: my-ca-issuer
spec:
  ca:
    secretName: root-secret

“selfsigned-issuer” ClusterIssuer 用于颁发根 CA 证书。然后，“my-ca-issuer” ClusterIssuer 用于颁发，但也使用新创建的根 CA Certificate 签名证书，您将在整个集群中使用该证书来签署未来的证书。

CRL 分发点

您也可以选择将 CRL 分发点指定为字符串数组，每个字符串标识 CRL 的位置，可以在其中检查已颁发证书的吊销状态。

...
spec:
  selfSigned:
    crlDistributionPoints:
    - "http://example.com"

注意事项

信任

使用 SelfSigned 证书的客户端无法信任它们，除非事先已拥有证书，而在客户端与服务器位于不同的命名空间时，这可能难以管理。

此限制可以通过使用 trust-manager 将 ca.crt 分发到其他命名空间来解决。

没有解决分发信任存储问题的安全替代方法；可以“TOFU”（首次使用信任）证书，但这种方法容易受到中间人攻击。

证书有效性

证书自签名的一个副作用是它的主体 DN 与它的颁发者 DN 相同。X.509 RFC 5280，第 4.1.2.4 节要求

颁发者字段必须包含一个非空的识别名称 (DN)。

但是，自签名证书默认情况下没有设置主体 DN。除非您手动设置证书的主体 DN，否则颁发者 DN 将为空，并且证书在技术上将无效。

对规范的这个特定区域的验证是不完整的，并且在不同的 TLS 库之间有所不同，但始终存在库会在未来改进其验证——完全符合规范——并破坏您使用空颁发者 DN 的证书的应用程序的风险。

为了避免这种情况，请确保为 SelfSigned 证书设置一个主体。这可以通过在 cert-manager Certificate 对象上设置 spec.subject 来完成，该对象将由 SelfSigned 颁发者颁发。

从 1.3 版开始，如果 cert-manager 检测到由 SelfSigned 颁发者创建的证书具有空颁发者 DN，它将发出一个 Kubernetes 警告事件，类型为 BadConfig。

自签名

部署

引导 CA 颁发者

CRL 分发点

注意事项

信任

证书有效性

引导 `CA` 颁发者