///

要从用户的视角**了解 HTTPS 的基础知识**，请查看 <a href="https://howhttps.works/" class="external-link" target="_blank">https://howhttps.works/</a>。

现在，从**开发人员的视角**，在了解 HTTPS 时需要记住以下几点：

* 要使用 HTTPS，**服务器**需要拥有由**第三方**生成的**"证书(certificate)"**。
     * 这些证书实际上是从第三方**获取**的，而不是“生成”的。
* 证书有**生命周期**。
     * 它们会**过期**。
     * 然后它们需要**更新**，**再次从第三方获取**。
* 连接的加密发生在 **TCP 层**。
     * 这是 HTTP 协议**下面的一层**。
     * 因此，**证书和加密**处理是在 **HTTP之前**完成的。

* Allows extension API server to dynamically discover the requestheader CA certificate when the core API server doesn't use certificate based authentication for it's clients ([#66394](https://github.com/kubernetes/kubernetes/pull/66394), [@rtripat](https://github.com/rtripat))

      calls.add("checkServerTrusted " + certificatesToString(chain))
    }

    private fun certificatesToString(certificates: Array<X509Certificate>): String {
      val result: MutableList<String> = ArrayList()
      for (certificate in certificates) {
        result.add(certificate.subjectDN.toString() + " " + certificate.serialNumber)
      }
      return result.toString()
    }
  }

  /**

				"application/vnd.airzip.filesecure.azs",
				"application/vnd.amazon.ebook",
				"application/vnd.americandynamics.acc",
				"application/vnd.amiga.ami",
				"application/vnd.anser-web-certificate-issue-initiation",
				"application/vnd.anser-web-funds-transfer-initiation",
				"application/vnd.antix.game-component",
				"application/vnd.apple.installer+xml",
				"application/vnd.apple.iwork",

	public final fun check (Ljava/lang/String;[Ljava/security/cert/Certificate;)V
	public fun equals (Ljava/lang/Object;)Z
	public final fun findMatchingPins (Ljava/lang/String;)Ljava/util/List;
	public final fun getPins ()Ljava/util/Set;
	public fun hashCode ()I
	public static final fun pin (Ljava/security/cert/Certificate;)Ljava/lang/String;

  - `status.conditions[*].status` is now required
  - `status.certificate` must be PEM-encoded, and contain only CERTIFICATE blocks ([#91685](https://github.com/kubernetes/kubernetes/pull/91685), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, Auth, CLI and Testing]

previously created the first bootstrap client credentials in the certificates directory as `kubelet-client.key` and `kubelet-client.crt`.  Subsequent certificates created by cert rotation were created in a combined PEM file that was atomically rotated as `kubelet-client-DATE.pem` in that directory, which meant clients relying on the `node.kubeconfig` generated by bootstrapping would never use a rotated cert.  The initial bootstrap certificate is now generated into the cert directory as a PEM file and symlinked...

  //
  // +optional
  optional ServiceReference service = 1;

  // `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
  // If unspecified, system trust roots on the apiserver are used.
  // +optional
  optional bytes caBundle = 2;

  in kube-apisever and kube-controller-manager pods. Instead, it shifted to supporting the
  mounting of /etc/pki/ca-trust and /etc/pki/tls/certs. The locations /etc/ca-certificate,
  /usr/share/ca-certificates, /usr/local/share/ca-certificates, and /etc/ssl/certs continued
  to be supported. ([#124361](https://github.com/kubernetes/kubernetes/pull/124361), [@neolit123](https://github.com/neolit123))

- Kubeadm: add support for certificate chain validation. When using kubeadm in external CA mode, this allows an intermediate CA to be used to sign the certificates. The intermediate CA certificate must be appended to each signed certificate for this to work correctly. ([#97266](https://github.com/kubernetes/kubernetes/pull/97266), [@robbiemcmichael](https://github.com/robbiemcmichael))...