身份认证之PKI搭建、X.509(RFC5280)——(一)

一.PKI的搭建

利用openssl搭建一个功能简单的PKI
参考文档
https://pki-tutorial.readthedocs.io/en/latest/simple/index.html

这一部分不是原创,其实就是照着英文文档实现了一下,把英文文档翻译成了中文(如果想自己实现,最好按照这个英文文档来)

  • 概述

在这里插入图片描述

  • 这是一个名为Simple Inc的组织, 该组织运行一个小型PKI来保护其电子邮件和Internet流量。
  • 要构建PKI,我们首先创建根CA及其根CA证书。 然后,我们使用根CA来创建简单签名CA.当CA部署完成后,我们会向员工Fred颁发电子邮件保护证书,并向www.simple.org网站服务器颁发TLS服务器证书。最后,了解CA需要支持的输出格式,并展示如何查看我们创建的文件的内容。
  • 开始之前要获取Simple PKI示例文件并切换到新目录。
git clone https://bitbucket.org/stefanholek/pki-example-1
cd pki-example-1

1.创建根CA

1.1创建目录

  • 创建两个目录,CA目录包含了CA的相关信息,CRL目录里包含了CRL的信息。
    对CA目录修改权限。
mkdir -p ca/root-ca/private ca/root-ca/db crl certs
chmod 700 ca/root-ca/private

1.2创建数据库

cp /dev/null ca/root-ca/db/root-ca.db
cp /dev/null ca/root-ca/db/root-ca.db.attr
echo 01 > ca/root-ca/db/root-ca.crt.srl
echo 01 > ca/root-ca/db/root-ca.crl.srl
  • 在使用openssl ca命令之前,数据库文件必须存在。
    数据库中包含以下文件:索引文件,属性文件,证书序列号文件,CRL号码文件。这些文件的内容在附录B中描述。

1.3 生成Root CA请求

openssl req -new \
    -config etc/root-ca.conf \
    -out ca/root-ca.csr \
    -keyout ca/root-ca/private/root-ca.key
  • 使用openssl req -new命令,我们为根CA生成私钥和证书签名请求(CSR)。 系统会要求输入密码来保护私钥(可以随便输,类似于1111的简单密码)。openssl req命令从前文的配置文件的[req]部分获取其配置。

1.4生成Root CA证书

penssl ca -selfsign \
    -config etc/root-ca.conf \
    -in ca/root-ca.csr \
    -out ca/root-ca.crt \
    -extensions root_ca_ext
  • 使用openssl ca命令,我们发布基于1.3中CSR的证书。 该命令从前文的配置文件获取其配置。

2.创建 Signing CA

2.1创建目录

mkdir -p ca/signing-ca/private ca/signing-ca/db crl certs
chmod 700 ca/signing-ca/private
  • ca目录包含CA资源,crl目录包含CRL资源,certs目录包含用户证书。

2.2创建数据库

cp /dev/null ca/signing-ca/db/signing-ca.db
cp /dev/null ca/signing-ca/db/signing-ca.db.attr
echo 01 > ca/signing-ca/db/signing-ca.crt.srl
echo 01 > ca/signing-ca/db/signing-ca.crl.srl
  • 这些文件的内容在附录B中描述。

2.3创建Signing CA请求

openssl req -new \
    -config etc/signing-ca.conf \
    -out ca/signing-ca.csr \
    -keyout ca/signing-ca/private/signing-ca.key
  • 使用openssl req -new命令,我们为签名CA创建私钥和证书生成请求CSR。 系统会要求输入密码来保护私钥可以随便输,类似于1111的简单密码)。 openssl req命令从配置文件 [req]部分获取其配置。

2.4创建Signing CA证书

openssl ca \
    -config etc/root-ca.conf \
    -in ca/signing-ca.csr \
    -out ca/signing-ca.crt \
    -extensions signing_ca_ext
  • 使用openssl ca命令,我们发布基于CSR的证书。 该命令从配置文件的[ca]部分获取其配置。 注意,颁发签名CA证书的是根CA.

3.使用CA证书

3.1创建email请求

openssl req -new \
    -config etc/email.conf \
    -out certs/fred.csr \
    -keyout certs/fred.key
  • 使用openssl req -new命令,生成私钥和证书签名请求。
    request configuration file 是已经配置好的文件。
    出现提示时输入以下DN组件:
    DC=org,DC=simple,O=Simple Inc, CN=Fred Flintstone,
    emailAddress = fred@simple.org.其他字段留空。

3.2创建email证书

openssl ca \
    -config etc/signing-ca.conf \
    -in certs/fred.csr \
    -out certs/fred.crt \
    -extensions email_ext
  • 我们使用Signing CA颁发电子邮件的证书。 证书类型由我们附加的扩展名定义。 证书的副本以名称ca / signing-ca / 01.pem保存在证书归档中(01是十六进制的证书序列号。)

3.3 TLS服务器请求

SAN=DNS:www.simple.org \
openssl req -new \
    -config etc/server.conf \
    -out certs/simple.org.csr \
    -keyout certs/simple.org.key
  • 使用已经配置好的文件request configuration file生成TSL服务器证书的私钥和CSR。
    出现提示时输入以下DN组件:
    DC=org, DC=simple, O=Simple Inc, CN=www.simple.org
    必须将subjectAltName指定为环境变量。 另请注意,服务器密钥通常没有密码。

3.4生成TLS服务器证书

openssl ca \
    -config etc/signing-ca.conf \
    -in certs/simple.org.csr \
    -out certs/simple.org.crt \
    -extensions server_ext
  • 我们使用签名CA颁发服务器证书。 证书类型由我们附加的扩展名定义。 证书副本以名称ca / signing-ca / 02.pem保存在证书归档中。

3.5证书的吊销

openssl ca \
    -config etc/signing-ca.conf \
    -revoke ca/signing-ca/01.pem \
    -crl_reason superseded
  • 证书替换或私钥丢失时,要求在证书有效期到期之前撤销证书。 openssl ca -revoke命令将证书标记为在CA数据库中已撤销。 从那时起它将被包含在CA颁发的CRL中。 上面的命令撤消序列号为01(十六进制)的证书。

3.6证书撤销列表

openssl ca -gencrl \
    -config etc/signing-ca.conf \
    -out crl/signing-ca.crl
  • openssl ca -gencrl命令创建证书吊销列表(CRL)。CRL包含CA数据库中所有已撤销但尚未过期的证书。必须定期发布新的CRL。

4.输出格式

4.1生成DER格式的证书

openssl x509 \
    -in certs/fred.crt \
    -out certs/fred.cer \
    -outform der
  • 所有已发布的证书必须采用DER格式[RFC 2585#section-3]。

4.2生成DER格式的证书撤销列表

openssl crl \
    -in crl/signing-ca.crl \
    -out crl/signing-ca.crl \
    -outform der
  • 所有已发布的CRL必须采用DER格式[RFC 2585#section-3]

4.3 生成PKCS#7 bundle

openssl crl2pkcs7 -nocrl \
    -certfile ca/signing-ca.crt \
    -certfile ca/root-ca.crt \
    -out ca/signing-ca-chain.p7c \
    -outform der
  • PKCS#7用于绑定两个或多个证书。 格式也允许CRL,但它们在实践中不使用。

4.4生成PKCS#12 bundle

openssl pkcs12 -export \
    -name "Fred Flintstone" \
    -inkey certs/fred.key \
    -in certs/fred.crt \
    -out certs/fred.p12
  • PKCS#12用于绑定证书和私钥。 可以添加其他证书,通常是包含直到根CA的链的证书

4.5生成PEMbundl

cat ca/signing-ca.crt ca/root-ca.crt > \
    ca/signing-ca-chain.pem

cat certs/fred.key certs/fred.crt > \
    certs/fred.pem

  • PEM包是通过连接其他PEM格式的文件创建的。 最常见的形式是"cert chain",“key + cert"和"key + cert chain”。OpenSSL支持PEM包,大多数软件基于它(例如Apache mod_ssl和stunnel。)

5.查看结果

5.1查看请求的结果

openssl req \
    -in certs/fred.csr \
    -noout \
    -text
  • openssl req命令可用于显示CSR文件的内容。

5.2查看证书

openssl x509 \
    -in certs/fred.crt \
    -noout \
    -text
  • openssl x509命令可用于显示证书文件的内容
  • 结果如下图
    在这里插入图片描述

在这里插入图片描述

5.3查看CRL

openssl crl \
    -in crl/signing-ca.crl \
    -inform der \
    -noout \
    -text
  • openssl crl命令可用于查看CRL文件的内容。
  • 结果如下图:
    在这里插入图片描述

5.4查看PKCS#7 bundle

openssl pkcs7 \
    -in ca/signing-ca-chain.p7c \
    -inform der \
    -noout \
    -text \
    -print_certs
  • openssl pkcs7命令可用于显示PKCS#7的内容。

5.4查看PKCS#12 bundle

openssl pkcs12 \
    -in certs/fred.p12 \
    -nodes \
    -info
  • openssl pkcs12命令可用于显示PKCS#12的内容。

二.PKI的基本概念

1.定义

  • PKI:公钥基础设施 Public Key Infrastructure
  • PKI的目的:解决网上身份认证、电子信息的完整性和不可抵赖性等安全问题,为网络应用提供可靠的安全服务。
  • PKI的任务:确立可信任的数字身份。

2.PKI的组成

  • 证书机构CA,注册机构RA,证书发布库,密钥备份与恢复,证书撤销机构

  • 数字认证中心(CA)

    (1)负责发放和管理数字证书

    (2)提供网络身份认证服务、负责证书签发及签发后证书生命周期中的所有方面的管理

    (3)维护证书档案和证书相关的审计
    证书机构的功能:
    在这里插入图片描述

  • 注册机构

    注册机构(RA)是数字证书注册审批机构,是认证中心的延伸。

    RA按照特定政策与管理规范对用户的资格进行审查。
    注册机构的功能
    在这里插入图片描述

  • 证书发布库

    用于集中存放CA颁发证书和证书撤销列表。支持分布式存放,以提高查询效率。

    LDAP目录服务支持分布式存放,是大规模PKI系统成功实施的关键,也是创建高效的认证机构的关键技术。

  • 密钥备份与恢复

    密钥备份和恢复只能针对加/解密密钥,而无法对签名密钥进行备份。数字签名是用于支持不可否认服务的,有时间性要求,因此不能备份/恢复签名密钥。

    如果注册声明公/私钥对是用于数据加密的,则CA即可对该用户的私钥进行备份。当用户丢失密钥后,可通过可信任的密钥恢复中心或CA完成密钥恢复。

  • 证书撤销的两种实现方法

    (1)证书撤销列表
    (CRL, Certificate Revocation List)

    (2)在线证书状态协议
    (OCSP,Online Certificate Status Protocol)

三.数字证书及认证路径

1.数字证书

1998年,v1版本

1993年,v2版本,比v1版本增加了2个字段

1996,v3版本(v3格式通过添加其他扩展字段的规定来扩展v2格式)。

2.数字证书认证路径

在这里插入图片描述

在这里插入图片描述

3.Certificate Revocation证书撤销

  • 在证书有效期中间,该证书可能无效,如:私钥丢失
    身份信息发生变化。应该阻止订户停止使用该证书,CA要撤销该证书。
  • (1)Certificate Revocation List证书撤销列表
    也要CA进行数字签名,以实现数据完整性、数据源鉴别、非否认。
    下图为已被撤销的证书信息
    在这里插入图片描述
  • (2)Online Certificate Status Protocol联机证书撤销状态检查
    在这里插入图片描述
    由于CRL的更新是有周期的,所以在证书已经被撤销,但是CRL还没有更新的情况下就无法查询到最新状态,此时应该使用ocsp来进行实时的查询。
    请求-应答
    请求:“证书序列号等于****”的状态如何?
    应答:未撤销/撤销/未知
    应答消息需要服务器的数字签名

4.Operational Protocols

  • 需要协议来向使用证书的客户端系统提供证书和CRL。
    公开证书的方式:
    HTTP/FTP/LDAP/Email等等

5.Management Protocols管理协议

管理协议来支持PKI用户和管理实体之间的在线交互

  • (a)注册:这是在CA为该用户颁发证书或证书之前,用户首先使CA(直接或通过RA)知道自己的过程。
  • (b)初始化:在客户端系统可以安全运行之前,必须安装与存储在基础结构中其他位置的密钥具有适当关系的密钥材料。例如,客户端需要使用公钥和可信CA的其他保证信息进行安全初始化,以用于验证证书路径。此外,客户端通常需要使用自己的密钥对进行初始化。
  • (c)认证:这是CA为用户的公钥颁发证书,并将该证书返回给用户的客户端系统和/或将该证书发布到存储库中的过程。
  • (d)密钥对恢复:作为选项,用户客户端密钥材料(例如,用于加密目的的用户私钥)可以由CA或密钥备份系统备份。如果用户需要恢复这些备份的密钥材料(例如,由于忘记密码或丢失的密钥链文件),则可能需要在线协议交换来支持这种恢复。
  • (e)密钥对更新:所有密钥对需要定期更新,即用新密钥对替换,并颁发新证书。
  • (f)撤销请求:被授权人员向CA通知需要撤销证书的异常情况。
  • (g)交叉认证:两个CA交换用于建立交叉证书的信息。交叉证书是由一个CA颁发给另一个CA的证书,其中包含用于颁发证书的CA签名密钥。

四.证书

1.数字证书的具体内容

在这里插入图片描述

2.数字证书的整体结构

  • 证书的整体结构:证书内容、签名算法、签名结果。
    用ASN.1语法描述如下:
    在这里插入图片描述
  • 签名算法为CA对tbsCertificate进行签名所使用的算法;类型为AlgorithmIdentifier,其ASN.1语法描述如下
    在这里插入图片描述
  • 签名结果是CA对tbsCertificate进行签名的结果,类型为BIT STRING。
  • version
    版本号
    版本(version)为整数格式。证书格式的版本只有v1、v2、v3,分别用整数0、1、2表示。其类型Version的ASN.1描述如下:
    Version::=INTEGER {v1(0),v2(1),v3(2)}
  • issuer
    证书的签发者(issuer):签发证书的CA实体
  • subject
    证书主体(subject) :证书持有者实体
    证书的签发者和证书主体用X.509 DN表示,DN是由RDN构成的序列。RDN用“属性类型=属性值”的形式表示。常用的属性类型名称以及简写如下:
  • Serial number
    RFC 3280标准要求证书序列号必须是正整数,且长度不应该大于20字节
  • Signature algorithmidentifier
    CA签发证书时所使用的数字签名算法,它的类型与signatureAlgorithm的类型相同,都为AlgorithmIdentifier,它们的值必须一致,否则该证书无效
  • validity
    包含起、止两个时间值。时间值可以使用UTCTime或者GeneralizedTime的形式表示。
  • Subject publickey information
    给出了证书所绑定的加密算法和公钥
  • issuerUniqueID
    给出了证书签发者的唯一标识符
  • subjectUniqueID
    给出了证书主体的唯一标识符

3.数字证书的签名

在这里插入图片描述

4.数字证书的验证

在这里插入图片描述

五.数字证书的扩展

1.Authority Key Identifier 认证中心密钥标识

在这里插入图片描述

  • CA有多种功能:与RA通信,签发订户证书,签发CRL等。不同功能需要不同的证书
  • 认证中心密钥的作用:标识用来指定CA签发证书所用私钥对应的公钥,也就是指定了验证证书时所用的CA证书,有助于证书验证者更快地找到证书
  • 扩展值的ASN.1描述
    在这里插入图片描述

2.Subject Key Identifier 主体密钥标识

  • 订户会进行不同安全要求的业务,需要多个密钥/证书来对应不同的应用。

  • 主体密钥标识的作用:区分订户的各个密钥/证书对,也就是区分各个公钥

  • ASN.1描述
    在这里插入图片描述

该字段需要包含在所有证书中

3.Key Usage 密钥用法

  • 密钥用法扩展的作用:实体拥有多个密钥证书对,该扩展指定证书所对应密钥的允许用途。
  • ASN.1描述
    在这里插入图片描述
  • 具体用法

4.Certificate Policies 证书策略

  • X.509证书是用于安全服务的,应该在证书中区分其安全等级的不同
    (1)安全等级主要是体现在:
    证书产生过程:信息审查是不是严格
    证书使用:所使用领域的安全要求不同
  • (1)证书策略就是用来区分不同证书的安全等级的
    简称CP,以OID的形式
    (2)证书策略扩展的作用:以OID的形式区分不同证书的安全级别
  • 建立CA时就确定CA所能签发的证书的CP,如果想要在CA运行中间增加支持新的CP很困难。将CA证书中OID设为2.5.29.32.0,即any-policy
  • CA位置不同,意义不同
    (1)CP出现在CA证书
    CA证书中有5个CP(ABCDE)
    表示该CA可以签发具有这种CP的订户证书
    (2)CP出现在订户证书
    Bob证书中的CP是A级
    就说明了Bob证书具有此CP对应的安全等级
  • (1)1个CA可以具有几种不同的CP。1个CA可以支持多种不同的证书签发流程,签发的证书可用于多种安全等级的范围。
    (2)1个订户证书,可以具有几种不同的CP。签发流程自然只有1种,但可用于多种安全等级的范围应用系统检查的需要。

5.Certificate Mapping 证书映射

在这里插入图片描述

6.Subject Alternative Name&&issuer Alternative Name

  • 以上扩展用于表示CA/证书主体非X.500 DN形式的身份信息和名称表示(如IP地址,电子邮件)
  • 一般情况下设置为非关键性扩展
    subject和issuer字段为空时,或者含有重要的需要用户识别的名称形式时需设为关键字段

7.Subject Directory Attributes 主体目录属性

主体目录属性用于表示证书主体在X.500目录中的属性

8.Basic Constraint基本限制

  • 基本限制扩展用来区分该证书是CA证书还是末端实体证书
  • CA证书给出最大路径深度,为关键性扩展
  • 末端实体证书,关键或非关键扩展
*注:x.509 剩余部分将由身份认证小组其他同学来补充
  • 8
    点赞
  • 42
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
报错信息表明 kube-scheduler 无法加载客户端 CA 文件 `/etc/kubernetes/pki/ca.crt`,因为该文件不存在。这可能是由于文件路径不正确或缺少必要的证书文件。 要解决这个问题,您可以按照以下步骤进行操作: 1. 首先,请确认 `/etc/kubernetes/pki/` 目录中是否存在 `ca.crt` 文件。您可以使用以下命令检查该文件是否存在: ``` ls /etc/kubernetes/pki/ca.crt ``` 2. 如果文件不存在,可能是由于证书文件丢失或路径不正确。您可以尝试重新生成证书文件。 - 如果您使用的是 kubeadm 进行的 Kubernetes 安装,可以尝试运行以下命令来重新生成证书文件: ``` sudo kubeadm init phase certs all --apiserver-advertise-address=<your-address> ``` 注意将 `<your-address>` 替换为您的主机地址。 - 如果您使用的是其他方式进行的安装,请根据相应的文档或指南重新生成证书文件。 3. 如果证书文件确实存在于其他位置,请确保在 kube-scheduler 的配置文件中正确指定了客户端 CA 文件的路径。您可以打开 kube-scheduler 的配置文件(一般为 `/etc/kubernetes/scheduler.conf`)并检查 `--client-ca-file` 参数的值是否正确。 ``` --client-ca-file=/path/to/ca.crt ``` 将 `/path/to/ca.crt` 替换为实际的证书文件路径。 4. 保存配置文件并重新启动 kube-scheduler 进程,以使更改生效。 ``` sudo systemctl restart kube-scheduler ``` 这样应该能够解决无法加载客户端 CA 文件的问题。 如果问题仍然存在,请提供更多的上下文信息,以便我能够更好地帮助您解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值