1、Kubernetes 认证方式

　　Kubernetes集群的访问权限控制由API Server负责，API Server的访问权限控制由身份验证(Authentication)、授权(Authorization)和准入控制（Admission control）三个步骤组成，这个三个步骤是按序进行的（详细介绍请参见《(转)使用kubectl访问Kubernetes集群时的身份验证和授权》）。

其中身份验证这个环节它面对的输入是整个http request，它负责对来自client的请求进行身份校验，支持的方法包括：

  • CA 认证，基于CA根证书签名的双向数字证书认证
  • Token认证，通过Token识别每个合法的用户
  • Basic认证

　　API Server启动时，可以指定一种Authentication方法，也可以指定多种方法。如果指定了多种方法，那么APIServer将会逐个使用这些方法对客户端请求进行验证，只要请求数据通过其中一种方法的验证，API Server就会认为Authentication成功；在较新版本kubeadm引导启动的k8s集群的API Server初始配置中，默认支持CA认证和Token认证两种身份验证方式。在这个环节，API Server会通过client证书或http header中的字段(比如ServiceAccount的JWTToken)来识别出请求的“用户身份”，包括”user”、”group”等，这些信息将在后面的授权和准入控制环节用到。

在Kubernetes中，Kubectl和API Server、Kubelet和API Server、API Server和Etcd、Kube-Scheduler和API Server、Kube-Controller-Manager和API Server以及Kube-Proxy和API Server之间是基于CA根证书签名的双向数字证书方式进行认证，此方式是最为严格和安全的集群安全配置方式，也是我们本文介绍的主角；在Kubernetes中，集成的组件和API Server之间也可以选择配置基于CA根证书签名的双向数字证书方式进行认证，比如Metrics Servser；在Kubernetes中，Pod和API Server之间如果没有配置基于CA根证书签名的双向数字证书方式进行认证的话，则默认通过Token方式（ServiceAccount的JWTToken)）进行认证。

2、Kubernetes CA 认证涉及相关知识

在详细介绍Kubernetes CA认证之前，我们先简述下和Kubernetes CA认证相关的知识。

2.1 CA证书相关知识

  • 对称加密：指加密与解密使用同一密钥的方式，速度快，但密钥管理困难。
  • 非对称加密：指加密和解密使用不同密钥的方式，速度慢。公钥和私钥匙一一对应的，一对公钥和私钥统称为密钥对。由公钥进行加密的密文，必须使用与该公钥配对的私钥才能解密。密钥对中的两个密钥之间具有非常密切的关系——数学上关系——公钥和私钥匙不能分布单独生成的。它有两种用途：(1)加密传输过程：公钥加密，私钥解密；(2)签名过程：私钥加密，公钥解密。
  • 混合加密：将对称密钥与非对称密钥结合起来，这种系统结合了两者的优势。比如，SSL/TLS使用混合加密（Hybrid Encryption）的方式来保证通信的安全性，在混合加密中，使用非对称加密算法来协商对称密钥，然后使用对称加密算法来对通信过程中的数据进行加密和解密，以提供更高的安全性和效率。
  • 数字签名：数字签名是一种用于确保数字信息的完整性、身份认证和不可抵赖性的加密技术。数字签名是基于公钥加密和非对称密钥技术实现的，常被用于验证数字文档、软件、电子邮件等的真实性和完整性。数字签名的基本原理是将原始数据通过哈希函数（Hash Function）生成一个摘要（Digest），然后使用发送者的私钥对摘要进行加密，生成数字签名。接着，将原始数据和数字签名一起传输给接收者。接收者收到数据后，使用发送者的公钥对数字签名进行解密，得到摘要。然后，接收者对接收到的原始数据使用相同的哈希函数生成另一个摘要，将两个摘要进行比较，如果两个摘要一致，则表明原始数据没有被篡改过，数字签名也是合法的，否则就表明原始数据已经被篡改过或者数字签名不合法。要正确的使用数字签名，有一个大前提，那就是用于验证签名的公钥必须属于真正的发送者。
  • 证书：数字证书是基于公钥加密和非对称密钥技术实现的，通过数字证书可以验证一个数字实体的身份信息，简单来说证书就是为公钥加上数字签名。它是由数字证书颁发机构（CA，Certificate Authority）签发的一种数字文件，包含了证书持有者的身份信息和公钥等关键信息。数字证书通常包含以下信息：
    • 证书颁发机构的名称和公钥。
    • 证书持有者的名称、电子邮件地址和公钥等身份信息。
    • 证书有效期限和用途。
    • 证书颁发机构的数字签名。
  • CA（证书颁发机构）：CA是一个机构，专门为其他人签发证书，这个证书保存其他人的公钥，确保了公钥的来源且没有被篡改。CA本身有自己的公私钥对，私钥用于签发其他证书，公钥用于验证证书，CA公钥同样需要保护，这就是CA证书。那么CA证书是谁签发呢，从签名的原理来看，必然存在CA自己给自己签名，这就是根CA证书。根CA是非常宝贵的，通常出于安全的考虑会签发一些中间CA证书，然后由中间CA签发最终用户证书，这样就构成了一个信任链。接收者信任某个CA证书，那么由此CA签发的证书就都被信任。公信的根CA全球只有有限的一些，它们通过第三方机构审计，具有权威性和公正性，通常操作系统或浏览器已经内置安装，由这些根CA签发的证书都会被信任。用户也可以自行安装信任的证书，其风险需要用户自己承担，一定要确保证书来源可靠。
  • 根证书（自签名证书）：根证书是CA认证中心给自己颁发的证书,是信任链的起始点。

2.2 HTTPS双向认证流程

Kubernetes CA认证也叫HTTPS证书认证，其认证原理便是HTTPS双向认证，下面着重说下HTTPS双向认证流程：

3、Kubernetes 基于CA根证书签名的双向数字证书认证

下面以Kubectl（客户端）和API Server（服务端）认证为例，讲解基于CA根证书签名的双向数字证书认证。

3.1 API Server证书配置

使用Kubeadm初始化的Kubernetes集群中，API Server是以静态Pod的形式运行在Master Node上。 可以在Master Node上找到其定义文件/etc/kubernetes/manifests/kube-apiserver.yaml，其中启动命令参数部分如下：

spec:

  containers:

  - command:

    - kube-apiserver

    - --advertise-address=10.20.30.31

    - --allow-privileged=true

    - --audit-log-maxage=30

    - --audit-log-maxbackup=10

    - --audit-log-maxsize=100

    - --audit-log-path=/data/lc/log/t-audit.log

    - --authorization-mode=Node,RBAC

    - --bind-address=0.0.0.0

    - --client-ca-file=/etc/kubernetes/pki/ca.crt

    - --enable-admission-plugins=NodeRestriction

    - --enable-bootstrap-token-auth=true

    - --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem

    - --etcd-certfile=/etc/ssl/etcd/ssl/node-node1.pem

    - --etcd-keyfile=/etc/ssl/etcd/ssl/node-node1-key.pem

    - --etcd-servers=https://10.20.30.31:2379

    - --feature-gates=ExpandCSIVolumes=true,RotateKubeletServerCertificate=true,RemoveSelfLink=false,SuspendJob=true

    - --insecure-port=0

    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt

    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key

    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname

    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt

    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key

    - --requestheader-allowed-names=front-proxy-client

    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt

    - --requestheader-extra-headers-prefix=X-Remote-Extra-

    - --requestheader-group-headers=X-Remote-Group

    - --requestheader-username-headers=X-Remote-User

    - --secure-port=6443

    - --service-account-issuer=https://kubernetes.default.svc.cluster.local

    - --service-account-key-file=/etc/kubernetes/pki/sa.pub

    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key

    - --service-cluster-ip-range=10.233.0.0/18

    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt

    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

注意："API Server" 和 "kube-apiserver" 可以视为同义词，都是 Kubernetes 中核心的 API 处理器，但 "kube-apiserver" 是 Kubernetes 中默认的 API Server 实现。

API Server作为服务端时，我们注意到有如下三个启动参数：

  • --client-ca-file: 指定CA根证书文件为/etc/kubernetes/pki/ca.crt，内置CA公钥用于验证某证书是否是CA签发的证书，Kubectl和Kube-Apiserver之间认证的话，ca.crt用于验证Kubectl的客户端证书是否是CA签发的证书。
  • --tls-cert-file：指定Kube-Apiserver证书文件为/etc/kubernetes/pki/apiserver.crt
  • --tls-private-key-file: 指定Kube-Apiserver私钥文件为/etc/kubernetes/pki/apiserver.key

在Master Node上进入/etc/kubernetes/pki/目录：

[root@node1 pki]# pwd

/etc/kubernetes/pki

[root@node1 pki]# ls

apiserver.crt  apiserver-kubelet-client.crt  ca.crt  front-proxy-ca.crt  front-proxy-client.crt  sa.key

apiserver.key  apiserver-kubelet-client.key  ca.key  front-proxy-ca.key  front-proxy-client.key  sa.pub

查看CA根证书ca.crt：

[root@node1 pki]# openssl x509 -noout -text -in ca.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 0 (0x0)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=kubernetes

        Validity

            Not Before: Apr 19 03:11:19 2022 GMT

            Not After : Apr 16 03:11:19 2032 GMT

        Subject: CN=kubernetes

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:bd:27:a0:73:45:58:b9:f4:90:27:53:77:02:ff:

                    8e:9b:f3:5a:14:d7:85:08:c8:17:8f:cb:66:54:61:

                    47:d3:59:3c:97:c0:bb:a0:63:c6:2a:eb:cb:07:ec:

                    f7:b1:06:e2:68:07:71:67:93:10:27:80:c0:2f:e2:

                    93:3f:34:ab:de:68:eb:3a:af:71:5e:18:71:be:e0:

                    06:9f:3c:97:f7:52:5e:fd:8a:2d:de:fd:bc:5e:be:

                    c1:51:7e:38:9b:ac:25:79:68:00:26:a4:61:e7:5f:

                    30:32:bb:af:39:fb:aa:58:eb:98:b6:ac:ab:31:50:

                    6c:bd:64:38:2d:16:5e:96:db:ba:ce:d1:ce:90:83:

                    a6:03:76:55:e7:af:6c:8d:2e:c5:52:18:8b:77:6f:

                    d3:fb:1c:cb:c9:01:8b:8f:7b:4d:a4:0c:07:8d:0d:

                    18:69:ac:1b:14:90:61:99:f8:8f:b8:ca:52:2e:2b:

                    8a:87:7a:15:5e:b1:3f:1a:1b:8e:a3:87:dc:3d:f1:

                    1a:3c:30:8f:cf:2e:20:eb:d9:2c:a4:5f:80:6e:cb:

                    f1:e1:db:68:f3:a7:40:88:f8:7f:df:0d:1d:af:ac:

                    f2:aa:ec:12:65:69:8e:c7:2a:42:2e:38:e6:16:b5:

                    1f:de:26:de:4f:e8:ec:c6:76:22:ce:3c:59:4d:46:

                    6e:49

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Key Usage: critical

                Digital Signature, Key Encipherment, Certificate Sign

            X509v3 Basic Constraints: critical

                CA:TRUE

            X509v3 Subject Key Identifier:

                D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77

    Signature Algorithm: sha256WithRSAEncryption

         25:b2:9b:94:fb:0f:5c:50:2f:cd:4f:b3:54:97:3c:ee:b3:65:

         f7:19:4a:6a:d5:ad:48:0b:f9:8e:56:0f:60:a3:7e:6e:48:62:

         9b:60:1e:a3:91:d7:60:f7:96:43:5c:5b:ab:96:99:cd:2d:86:

         19:de:e7:12:2e:17:2b:b6:93:50:e7:a3:74:3d:9e:cf:b5:58:

         88:dc:6a:29:48:7d:57:2d:e6:a6:9b:ee:2f:ce:fa:5e:74:ba:

         42:40:72:c5:fa:37:5a:03:f8:19:27:69:b3:87:be:2f:ca:ae:

         9d:8e:ae:83:c3:8d:1a:45:55:23:b5:c9:d6:08:9b:6e:f7:0a:

         ee:12:67:b2:24:52:e1:a8:01:35:82:0b:1d:5f:10:56:b4:b5:

         ea:4a:b8:8f:0e:4c:93:dd:a8:71:37:32:27:66:20:ca:ec:5d:

         f7:14:9e:8a:b7:82:18:b7:55:38:4a:a5:4b:1c:73:d7:b5:7e:

         a1:f5:f8:e3:4c:ab:73:62:41:23:12:91:42:12:06:8d:84:81:

         4d:30:d3:dc:14:7c:c7:a4:ab:76:fd:c7:3b:1c:42:eb:7b:23:

         92:1a:11:fe:63:12:22:ea:76:d2:fd:e1:9d:0b:74:77:6b:04:

         9f:a1:96:49:bc:f1:fc:9c:55:8f:19:ac:d5:f0:ac:e4:3c:d7:

         bd:5e:f7:65

注意：查看证书的方式有很多，不只可以通过openssl工具，也可以通过在线SSL网站解析证书，比如：SSLeye。

验证CA根证书ca.crt证书的合法性：

[root@node1 pki]# openssl verify -CAfile ca.crt ca.crt

ca.crt: OK

注意：我们知道验证证书合法性，就是用公钥验证证书的数字签名，由于CA根证书是自签名证书，公钥和数字签名信息都在ca.crt证书文件中，所以用以上命令验证ca.crt证书的合法性即可。

查看ApiServer的证书apiserver.crt：

[root@node1 pki]# openssl x509 -noout -text -in apiserver.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 7066543051370023677 (0x621167770eea4afd)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=kubernetes

        Validity

            Not Before: Apr 19 03:11:19 2022 GMT

            Not After : Apr 16 03:11:19 2032 GMT

        Subject: CN=kube-apiserver

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                ......

        X509v3 extensions:

            X509v3 Key Usage: critical

                Digital Signature, Key Encipherment

            X509v3 Extended Key Usage:

                TLS Web Server Authentication

            X509v3 Basic Constraints: critical

                CA:FALSE

            X509v3 Authority Key Identifier:

                keyid:D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77

            X509v3 Subject Alternative Name:

                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:lb.xxx.local, DNS:localhost, DNS:node1, DNS:node1.cluster.local, IP Address:10.233.0.1, IP Address:10.20.30.31, IP Address:127.0.0.1

   ......

验证apiserver.crt由ca.crt签发：

[root@node1 pki]# openssl verify -CAfile ca.crt apiserver.crt

apiserver.crt: OK

3.2 生成Kubectl客户端私钥和证书

客户端要通过HTTPS证书双向认证的形式访问ApiServer需要生成客户端的私钥和证书，其中客户端证书的在生成时-CA参数要指定为ApiServer的CA根证书文件/etc/kubernetes/pki/ca.crt，-CAkey参数要指定为Api Server的CA key /etc/kubernetes/pki/ca.key。

下面生成客户端私钥和证书：

cd /etc/kubernetes/pki/

// 生成kubectl客户端私钥

openssl genrsa -out client.key 2048

// 基于kubectl客户端私钥生成kubectl客户端证书签名请求文件client.csr，其中CN代表k8s用户，O代表k8s组

openssl req -new -key client.key -subj "/CN=10.20.30.31/O=system:masters" -out client.csr

// 基于证书请求文件、根CA证书、根CA私钥纯生成kubectl客户端证书

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650

注意 1：在 X.509 数字证书中，Subject 字段是用于表示证书拥有者的字段之一，通常包含多个子字段，用于描述证书拥有者的不同属性。下面是 Subject 字段中常见的子字段以及它们的含义：

  • C (Country): 表示证书拥有者所在的国家或地区的 ISO 3166-1 代码。

  • ST (State or Province): 表示证书拥有者所在的州或省份的全名或简称。

  • L (Locality): 表示证书拥有者所在的城市或城镇的名称。

  • O (Organization Name): 表示证书拥有者的组织名称。

  • OU (Organizational Unit Name): 表示证书拥有者的组织中的部门或单位名称。

  • CN (Common Name): 表示证书拥有者的通用名称，通常是证书关联的域名。

  • Email: 表示证书拥有者的电子邮件地址。

除了上述常见的子字段外，Subject 字段还可以包含其他自定义的子字段，用于描述证书拥有者的其他属性。需要注意的是，Subject 字段中的属性并非必须全部存在，具体哪些属性需要包含取决于证书颁发机构的要求。在生成kubectl客户端证书签名请求文件时，只是指定了证书拥有者的CN和O属性，分别代表k8s用户和组，其中组信息确定了kubectl客户端在k8s集群中的角色。（详细介绍请参见《(转)使用kubectl访问Kubernetes集群时的身份验证和授权》）

注意 2：.srl 是 OpenSSL 工具生成 X.509数字证书时自动生成的一个文件，用于记录证书的序列号。在生成证书时，每个证书都会被分配一个唯一的序列号，该序列号会被包含在证书中，并且存储在 .srl 文件中。由于 .srl 文件仅包含证书的序列号，因此通常可以安全地删除该文件，而不会影响现有的证书。

查看生成的kubectl客户端证书client.crt：

[root@node1 pki]# openssl x509 -noout -text -in client.crt

Certificate:

    Data:

        Version: 1 (0x0)

        Serial Number:

            fb:f7:2d:e5:58:8c:23:d5

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=kubernetes

        Validity

            Not Before: Apr  8 12:15:49 2023 GMT

            Not After : Apr  5 12:15:49 2033 GMT

        Subject: CN=10.20.30.31, O=system:masters

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                ......

    Signature Algorithm: sha256WithRSAEncryption

         ......

验证kubectl客户端证书client.crt是由ca.crt签发：

[root@node1 pki]# openssl verify -CAfile ca.crt client.crt

client.crt: OK

3.3 使用生成的Kubectl客户端私钥和证书访问ApiServer

[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 \

> --certificate-authority=ca.crt  \

> --client-certificate=client.crt \

> --client-key=client.key \

> get nodes

NAME           STATUS   ROLES                         AGE    VERSION

harbor-slave   Ready    worker                        11d    v1.21.5

node1          Ready    control-plane,master,worker   354d   v1.21.5

注意 1：如果执行kubectl客户端命令报如下错误：

[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 \

> --certificate-authority=ca.crt  \

> --client-certificate=client.crt \

> --client-key=client.key \

> get nodes

Error in configuration:

* client-cert-data and client-cert are both specified for kubernetes-admin. client-cert-data will override.

* client-key-data and client-key are both specified for kubernetes-admin; client-key-data will override

请通过以下命令查看 kubectl 是否之前加入过别的 k8s 集群：

[root@node1 pki]# kubectl config view

apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: DATA+OMITTED

    server: https://10.20.30.31:6443

  name: cluster.local

contexts:

- context:

    cluster: cluster.local

    user: kubernetes-admin

  name: kubernetes-admin@cluster.local

current-context: kubernetes-admin@cluster.local

kind: Config

preferences: {}

users:

- name: kubernetes-admin

  user:

    client-certificate-data: REDACTED

    client-key-data: REDACTED

在问题节点执行如下命令，用于清空 kubectl 的配置（或者一般情况下直接删除/root/.kube/config文件即可），执行完以下命令后再执行kubectl命令便不会再报此错误。

$ /usr/bin/kubectl config unset users

$ /usr/bin/kubectl config unset clusters

$ /usr/bin/kubectl config unset contexts

注意 2：本文主要讲解基于CA证书的双向认证方式，如果执行kubectl客户端命令报cannot list resource "nodes" in API错误，请检查kubectl客户端证书拥有者所属组关联的role是否拥有访问node资源权限。

4、总结

　　在Kubernetes中，Kubectl和API Server、Kubelet和API Server、API Server和Etcd、Kube-Scheduler和API Server、Kube-Controller-Manager和API Server以及Kube-Proxy和API Server之间是基于CA根证书签名的双向数字证书方式进行认证；在Kubernetes中，集成的组件和API Server之间也可以选择配置基于CA根证书签名的双向数字证书方式进行认证，比如Metrics Servser。

　　Kubernetes组件之间使用基于CA证书的双向认证方式可以带来以下好处：

  • 更高的安全性：双向认证可以确保客户端和服务器之间的通信是双向加密的，从而提高了通信的安全性，减少了数据泄露和中间人攻击等风险。

  • 认证客户端身份：使用双向认证可以让服务器验证客户端的身份，并且只有被授权的客户端才能访问服务器，从而减少了恶意攻击和未经授权的访问。

  • 降低攻击风险：在双向认证中，服务器会要求客户端提供证书，这样可以避免一些恶意攻击，比如伪造证书的攻击等。

  • 确保数据完整性：双向认证可以确保客户端和服务器之间的通信是完整的，没有被篡改或修改过的数据。

　　总之，双向认证可以提供更高的安全性和保护，减少了攻击风险，同时确保了数据的完整性和保密性，因此在 Kubernetes 中使用双向认证是一种非常有效的安全措施。

参考：Kubernetes构建自定义admission webhook

参考：(转)使用kubectl访问Kubernetes集群时的身份验证和授权

Kubernetes客户端认证——基于CA证书的双向认证方式的更多相关文章

  1. 基于SSL协议的双向认证 - SSL协议 [1]

    1  概要说明 在互联网通信方式中,目前用的最广泛的是HTTPS配合SSL和数字证书来保证传输和认证安全了. 2  详细介绍 2.1    HTTPS HTTPS全称:Hypertext Transf ...

  2. 高可用Kubernetes集群-2. ca证书与秘钥

    四．CA证书与秘钥 kubernetes集群安全访问有两种方式:"基于CA签名的双向数字证书认证"与"基于BASE或TOKEN的简单认证",生产环境推荐使用&q ...

  3. SSL使用windows证书库中证书实现双向认证

    前一段时间对OpenSSL库中的SSL通讯稍微琢磨了一下,在百度文库中找了个示例程序,然后在机器上跑,哇塞,运行成功!那时那个惊喜啊,SSL蛮简单的嘛.前几天,老板要我整一个SSL通讯,要使用wind ...

  4. k8s基于CA签名的双向数字证书认证（三）

    1.设置kube-apiserver的CA证书相关的文件和启动参数   1)创建CA证书和私钥相关的文件 openssl genrsa -out ca.key openssl req -x509 -n ...

  5. 基于SSL协议的双向认证 - 数字证书 [2]

    1.1    数字证书 1.1.1   概念理解 一种文件的名称,例如一个机构或人的签名,能够证明这个机构或人的真实性.简而言之数字证书是一种网络上证明持有者身份的文件,同时还包括有公钥.证书是由国际 ...

  6. 基于SSL协议的双向认证 - 双向认证 [3]

    1      SSL双向认证的实现 这里是基于SSL和Tomcat配置实现的,配置方法如下: 1.1    生成CA数字证书 首先需要配置OPENSSL环境变量. 我的OPENSSL配置文件路径是“D ...

  7. 基于java的https双向认证,android上亦可用

    From: http://my.oschina.net/jjface/blog/339144 概述: 客户端,浏览器或者使用http协议和服务器通信的程序. 如: 客户端通过浏览器访问某一网站时,如果 ...

  8. CA证书申请、认证原理

    (一) 证书的申请 密钥文件的格式用OpenSSL生成的就只有PEM和DER两种格式,PEM的是将密钥用base64编码表示出来的,直接打开你能看到一串的英文字母,DER格式是二进制的密钥文件,直接打 ...

  9. Https：创建部署SSL证书进行双向认证

    一.前言 建立客户端与服务器的Https的连接需要证书进行双向验证后,才可访问.   二.证书类型 不同数字证书部署在服务器上后,用户浏览器访问网站时,展示如下: 1.无证书时 显示不安全标识. 2. ...

  10. 使用自签CA,Server,client证书和双向认证

    服务端代码 package main import ( "crypto/tls" "crypto/x509" "google.golang.org/g ...

随机推荐

  1. Verilog中端口的连接规则

    摘自于(15条消息) Verilog中端口应该设置为wire形还是reg形_CLL_caicai的博客-CSDN博客, 以及(15条消息) Verilog端口连接规则_「已注销」的博客-CSDN博客_ ...

  2. 高并发解决方案之 redis 分布式锁

    背景:秒杀服务中要写一个定时任务:活动到期时给order微服务发送关闭订单的通知.这需要改变数据库表中的数据,而集群中服务是多节点的方式进行部署,会出现并发执行的情况,所以采用的redis的分布式锁的 ...

  3. C语言初级阶段7——指针2——特殊指针

    C语言初级阶段7--指针2--特殊指针 指针函数:是一个函数,返回值类型是一个指针. #include<stdio.h> int* fun() { //a是一个局部变量 int a = 1 ...

  4. 纯前端实现后端给数据进行文件导出——angular里面的使用

    interface dataList { cmd_cnt: number; risk_name: string; user_cnt: number; risk_type:string; } listO ...

  5. Manage your references to .Net assemblies Dynamics 365 for Operations VS projects

    (Dynamics 365 for Operations was previously known as the New Dynamics AX) Dynamics 365 for Operation ...

  6. Arrays.asList()需要注意的点

    千万不要这样使用Arrays.asList ! 测试的几种情况及原因: public static void main(String[] args) { //第一种基本类型数组 int[] arr = ...

  7. 字符串练习2 最长抑或路径（01trie树）

    题目链接在这里:P4551 最长异或路径 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn) 是一道比较经典的问题,对于异或问题经常会使用01trie树来解决. 当然01trie树只是用 ...

  8. js实现切换页面清除定时器的函数

    背景: 我在切换页面的时候,发现切换回原来的页面,定时器会叠加而不会清除原来的定时器 解决方法: 1.定义全局变量,通过js遍历清除(不会用,但性能好) var pageTimer = {} ; // ...

  9. buuoj.cn-web刷题记录-笔记

    1.万能密码 [极客大挑战 2019]EasySQL username=admin' or '1'='1&password=admin' or '1'='1 因为拼接为sql 会变成  sel ...

  10. 手写一个简易的ajax

    function ajax(url,successFul){ const xhr=new XMLHttpRequest() xhr.open("Get",url,true) xhr ...