22.加密与安全相关,证书申请CA（gpg，openssl)

最新推荐文章于 2021-12-07 19:04:34 发布

weixin_34319640

最新推荐文章于 2021-12-07 19:04:34 发布

阅读量326

点赞数

文章标签：数据库操作系统开发工具

原文链接：http://blog.51cto.com/14228129/2384475

版权

安全机制

信息安全防护的目标
保密性 Confidentiality
完整性 Integrity
可用性 Usability
可控制性 Controlability
不可否认性 Non-repudiation
安全防护环节
物理安全：各种设备/主机、机房环境
系统安全：主机或设备的操作系统
应用安全：各种网络服务、应用程序
网络安全：对网络访问的控制、防火墙规则
数据安全：信息的备份与恢复、加密解密
管理安全：各种保障性的规范、流程、方法

安全***： STRIDE

Spoofing 假冒
Tampering 篡改
Repudiation 否认
Information Disclosure 信息泄漏
Denial of Service 拒绝服务
Elevation of Privilege 提升权限

其中拒绝服务是比较难以防止的，对方可以使用高流量导致网络瘫痪，以及IP更换等手段防止被禁。

安全设计基本原则

使用成熟的安全系统
以小人之心度输入数据
外部系统是不安全的
最小授权
减少外部接口
缺省使用安全模式
安全不是似是而非
从STRIDE思考
在入口处检查
从管理上保护好你的系统

安全算法

常用安全技术
认证：密码，生物指纹，虹膜等
授权
审计
安全通信
加密算法和协议
对称加密
公钥加密
单向加密
认证协议

对称加密算法

对称加密：加密和解密使用同一个密钥
DES：Data Encryption Standard，56bits
3DES：
AES：Advanced (128, 192, 256bits)
Blowfish，Twofish
IDEA，RC6，CAST5
特性：
1、加密、解密使用同一个密钥，效率高
2、将原始数据分割成固定大小的块，逐个进行加密
缺陷：
1、密钥过多
2、密钥分发：密钥在双方的传输过程中容易被偷取
3、数据来源无法确认：无法确认数据是否是真正的发送方发送

非对称加密算法

公钥加密：密钥是成对出现
公钥：公开给所有人；public key
私钥：自己留存，必须保证其私密性；secret key
特点：用公钥加密数据，只能使用与之配对的私钥解密；反之亦然
功能：
数字签名：主要在于让接收方确认发送方身份（利用发送方的私钥加密部分数据，比如加密）
对称密钥交换：发送方用对方的公钥加密一个对称密钥后发送给对方
数据加密：适合加密较小数据
缺点：密钥长，加密解密效率低下
算法：
RSA（既可以加密，也可数字签名）
DSA（只能数字签名）
ELGamal

非对称加密

基于一对公钥/密钥对
用密钥对中的一个加密，另一个解密
实现加密：
接收者
生成公钥/密钥对：P和S
公开公钥P，保密密钥S
发送者
使用接收者的公钥来加密消息M
将P(M)发送给接收者
接收者
使用密钥S来解密：M=S(P(M))
实现数字签名：
发送者
生成公钥/密钥对：P和S
公开公钥P，保密密钥S
使用密钥S来加密消息M
发送给接收者S(M)
接收者
使用发送者的公钥来解密M=P(S(M))

单向散列（哈希算法）

将任意数据缩小成固定大小的“指纹”
任意长度输入
固定长度输出
若修改数据，指纹也会改变（“不会产生冲突”）
若数据一样，则指纹也相同
无法从指纹中重新生成数据（“单向不可逆”）
功能：数据完整性，可以把结果和与原数据看做是相互一一对应的映射
常见算法
md5: 128bits、 sha1: 160bits、 sha224、 sha256、 sha384、 sha512
常用工具和命令：
md5sum | sha1sum [ --check ] file ：还有sha512sum等等
openssl、 gpg
rpm -V

数字签名：将hash计算之后的结果摘要利用私钥加密之后便被称为数字签名。

利用对称加密、非对称加密，以及hash算法，分别取它们的优点长处，则可以实现最好的加密传输方式：
1. 即解决了传输过程中的数据来源确认：利用非对称加密中的私钥加密原数据hash之后的摘要（也就是做成数字签名），对方收到可用公钥解密（此数字签名）来判断来源。
2. 同时又解决了加密解密的时间长短问题：主要利用对称加密来加密原数据以及数字签名组合成的数据，然后传输它，减少解密时间。
3. 并且又解决了密钥的交换问题：因为要利用对称加密解决时间问题，因此对称加密的密钥需要双方交换，则交换的时候为了安全利用了非对称加密的公钥来加密此密钥，并随着2中加密后的数据一起传输过去，只有对方才能解密此密钥，因此便保证了此密钥的安全。
比如a发送给b,则b最终收到了：key(data+Sa[hash(data)])+Pb(key)
其中key为对称加密的密钥，S为非对称加密私钥，P为费对称加密公钥。a,b代表属于a还是b。
1. 用接收方的非对称加密公钥加密后的对称加密密钥
2. 用对称加密密钥加密的原数据和数字签名的组合数据
  （数字签名可以利用发送方的非对称加密公钥解密得到原数据的hash值，然后与原数据进行比较可知原数据是否被串改）
https协议的服务就是用这种方式来实现数据加密的

示例应用程序：RPM

文件完整性的两种实施方式
被安装的文件
MD5单向散列
rpm --verify package_name (or -V)
发行的软件包文件
GPG公钥签名
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat* ：这个就是redhat公司包的公钥，redhat公司的rpm包的hash值都被它提前进行了私钥加密（数字签名）并存于rpm包的数据库中。而利用这公钥（导入本机系统之后）便可以对包的数字签名进行解密得出包的hash值，然后再与包本身计算得出的hash值进行比对来判断此包是否被篡改。yum也是同理。
rpm --checksig pakage_file_name (or -K)

密钥交换：主要利用公钥加密密钥并进行交换，密钥的生成可用DH算法；

密钥交换：IKE（ Internet Key Exchange ）主要有以下两种方式：

公钥加密密钥，然后私钥解密密钥，达到传输的效果（参考上面的过程）
DH算法双方计算出密钥：
DH (Deffie-Hellman)算法：生成会话密钥，由惠特菲尔德·迪菲（BaileyWhitfield Diffie）和马丁·赫尔曼（Martin Edward Hellman）在1976年发表
参看：https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
DH算法：
A: g,p 协商生成公开的整数g, 大素数p
B: g,p
A:生成隐私数据 :a (a< p )，计算得出 g^a%p，并将计算结果发送给B
B:生成隐私数据 :b,计算得出 g^b%p，并将计算结果发送给A
A:计算得出 [(g^b%p)^a] %p = g^ab%p，生成为密钥
B:计算得出 [(g^a%p)^b] %p = g^ab%p，生成为密钥

使用gpg实现对称加密

对称加密file文件
gpg -c file ：注意需要输入口令（密钥）
ls file.gpg
在另一台主机上解密file
gpg -o file -d file.gpg ：解密要输入和加密相同的口令（密钥）

gpg实现非对称加密

在hostB主机上用公钥加密，在hostA主机上解密
1. 在hostA主机上生成公钥/私钥对
  gpg --gen-key
2. 在hostA主机上查看公钥
  gpg --list-keys
3. 在hostA主机上导出公钥到zhanga.pubkey
  gpg -a --export -o zhanga.pubkey
4. 从hostA主机上复制公钥文件到需加密的B主机上
  scp zhanga.pubkey hostB:
5. 在需加密数据的hostB主机上生成公钥/私钥对
  gpg --list-keys
  gpg --gen-key
6. 在hostB主机上导入公钥
  gpg --import zhanga.pubkey
  gpg --list-keys
7. 在hostB上用导入的hostA的公钥，加密hostB主机的文件file,生成file.gpg：注意加密的时候不要写错所用的公钥了
  gpg -e -r zhanga file
  file file.gpg
8. 复制加密文件到hostA主机
  scp fstab.gpg hostA:
9. 在hostA主机解密文件
  gpg -d file.gpg
  gpg -o file -d file.gpg
10. 删除公钥和私钥(写上对应的名字)
  gpg --delete-keys zhanga
  gpg --delete-secret-keys zhanga

注意点1：

gen-key的时候要输入
- 加密算法
- 过期时间
- 用户姓名（至少5个字符）
- 邮箱
- 是否确认的信息

同时，输入确认之后会提醒输入口令对私钥进行再次加密（防止被窃取，保证私钥安全，也可以不输入口令）注意远程连接SSH时要unset DISPLAY命令才能显示出来输入密码的界面，不然会报错，详情查看帮助说明
最后它会利用鼠标的随机移动，硬件，键盘输入的字符等来生成密钥，有时会很慢（centos6中，7中不存在这个问题），可以在本机的图形界面进行生成加快速度。

生成的公私钥文件就在用户的家目录中的隐藏文件夹.gnupg中，公钥为punring.gpg ,私钥为 secring.gpg .
注意公钥导入的时候两台机器的时间必须同步，不然会显示没有自签名等错误。
想要删除本机的公钥必须先删除本机对应的私钥，当然删除导入的公钥的话没有这个要求。
删除了公钥之后如果反悔会有一个备份文件以波浪符结尾的公钥文件可供备份。

中间人***：公钥来源确认（公钥交换）造成

注意前面的这种key(data+Sa[hash(data)])+Pb(key) 方式也没有解决公钥交换的问题，无法确认公钥是否真的是对方的公钥。因此还需要用到下面证书的方法来进一步增加安全性。

CA和证书

PKI：Public Key Infrastructure
签证机构：CA（Certificate Authority）
注册机构：RA
证书吊销列表：CRL
证书存取库：
X.509：定义了证书的结构以及认证协议标准
版本号
序列号
签名算法
颁发者
有效期限
主体名称
主体公钥
CRL分发点
扩展信息
发行者签名

证书获取

证书类型：
证书授权机构的证书
服务器
用户证书
获取证书两种方法：
1. 使用证书授权机构
  生成证书请求（csr文件）
  将证书请求csr文件发送给CA
  CA签名颁发证书
2. 自签名的证书
  自已签发自己的公钥

注意点2：

证书申请方向证书颁发授权机构发送自己的信息以及公钥，申请证书。证书颁发授权机构CA 利用自己的私钥对证书申请方的各种信息进行加密并按照一定格式（参考上面所写）颁发证书，包含着此证书颁发机构的签名等。
- 然后证书申请人拿到证书之后便可以将它发送给需要交流通讯的其他目标方，这些目标方根据此证书的颁发机构的公钥来解密此证书，便可以得到证书申请人的各种信息包括它的公钥信息
- 同理这些目标方也可申请证书并发送给他人，这样双方就实现了自己的信息以及公钥的交换，保证了公钥交换过程的安全性。
- 通过这种第三方颁发证书的方式来解决了最后一个的公钥交换的安全和来源确认问题。
而证书颁发机构不一定是一个。多个不同的证书颁发机构的证书申请方之间的相互通讯过程是这样的：
- 比如说A由证书颁发机构CA1颁发证书，B由证书颁发机构CA2颁发证书。其中还有一个最上级的顶级证书颁发根机构CAroot
- 在1中我们假设了申请者都是在一个证书颁发机构内，都已拥有这个证书颁发机构的公钥。而目前的实际情况中证书的申请者拥有的是根颁发机构CAroot的公钥，而并不是直属的颁发机构的公钥。
- 这些直属的颁发机构也会向根颁发机构申请证书（相当于申请颁发证书的权限），而根颁发机构也会像1中所写对每一个下级证书颁发机构进行证书的颁发，里面就包含了这些证书颁发机构的公钥信息
- 因为所有的申请者都有根颁发机构CAroot的公钥，则他们就可以根据自己直属的颁发机构的被根颁发机构颁发的证书来解密得到自己直属的颁发机构的公钥信息，也就相当于多了一级解密过程。
- 根据这种方式，这些申请者也就能得到不是自己直属的颁发机构的其他颁发机构（需要通讯的对方的颁发机构）的证书，通过它来解出对方颁发机构的公钥（此时相当于拥有了多个颁发机构的公钥），然后再根据通讯对方的证书（这个证书是由对方颁发机构办法的，不是由根颁发证书颁发的，别搞混了颁发机构的证书和通讯方的证书，一个是由根颁发机构颁发，一个是由通讯方直属颁发机构颁发）利用这个公钥解出来通讯对方的公钥。
- 通过这种方式，即使通讯双方交换了不同颁发机构颁发的证书（同时也必须相互交换了这些不同颁发机构从根CAroot中所获得的证书），但也可得到对方颁发机构的公钥（就是利用颁发机构的证书和全部通讯方都已知的根CAroot的公钥解出),然后便可以将不同颁发机构的申请者之间的证书进行解密，从而得到了最终通讯方对方的公钥。
- 这样也就完成了通讯双方公钥的相互交换，然后便可进一步实行下一步的数据通信了。
注意2中的过程其实隐含了一个证书，就是根颁发机构CAroot自己给自己自签名颁发的证书（因为它就是顶级颁发机构，只能自己给自己颁发证书）。
根CAroot的公钥则是所有的申请者在新装机的时候内置的，相当于天生就知道这个公钥。不过要注意根CAroot不止一个，有很多个，这些根CA的公钥全部都会内置。
- 根CAroot的子CA的证书是由根CA颁发的，而用户的证书则是由这些子CA颁发的（也可以子CA再分子子CA，就是上面的2过程中每个通讯方再多拿一层颁发机构的证书而已，实际原理还是那些）

安全协议

SSL：Secure Socket Layer，TLS: Transport Layer Security（相同的算法，不同时期的名字）
1995：SSL 2.0 Netscape
1996：SSL 3.0
1999：TLS 1.0
2006：TLS 1.1 IETF(Internet工程任务组) RFC 4346
2008：TLS 1.2 当前使用
2015：TLS 1.3
功能：机密性，认证，完整性，重放保护（是否被二次发送）
两阶段协议，分为握手阶段和应用阶段
握手阶段(协商阶段):客户端和服务器端认证对方身份（依赖于PKI体系，利用数字证书进行身份认证），并协商通信中使用的安全参数、密码套件以及主密钥。后续通信使用的所有密钥都是通过MasterSecret生成
应用阶段:在握手阶段完成后进入，在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信
注意SSL/TLS协议放在应用层报头外面，对应用层的用户数据进行加密之后再由传输层进行传输。这样应用层的数据就无法被其他人看到了（即使被其他人获取也无法看到里面的内容）。

Handshake协议：包括协商安全参数和密码套件、服务器身份认证（客户端身份认证可选）、密钥交换
ChangeCipherSpec 协议：一条消息表明握手协议已经完成
Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告
Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等
HTTPS 协议：就是“HTTP 协议”和“SSL/TLS 协议”的组合。 HTTP overSSL” 或“HTTP over TLS”，对http协议的文本数据进行加密处理后，成为二进制形式传输

HTPTPS工作过程：

过程：

当用户访问服务器的时候（服务器已经提前申请好了证书),服务器便会把自己的证书发送给客户端。
客户端利用这个证书以及可信任的这个第三方颁发证书的机构的公钥（参考上面所写的过程），解密出服务器的公钥以及服务器的相关信息来进行验证（比如证书有效期，证书的所属的名字是否和服务器一致等等）
如果有效期等信息正确，然后客户端会生成一个随机数并利用解密出来的服务器的公钥进行加密返回传给服务器端。
服务器收到这个加密信息之后用自己的私钥进行解密，解密得到这个随机数，而这个随机数便会当做双方相互传输数据的密钥（对称加密）来进行数据传输。并且每隔一段时间更换一次此密钥，这样便实现了双方的加密和认证通讯。

OpenSSL

OpenSSL：开源项目，用于实现SSL协议的软件之一
三个组件：
openssl：多用途的命令行工具，包openssl
libcrypto：加密算法库，包openssl-libs
libssl：加密模块应用库，实现了ssl及tls，包nss
openssl命令：
两种运行模式：交互模式和批处理模式
openssl version：程序版本号
标准命令、消息摘要命令、加密命令
标准命令：enc, ca, req, ...

openssl命令1

对称加密：
工具：openssl enc, gpg
算法：3des, aes, blowfish, twofish
enc命令：
帮助：man enc
加密（需要输入口令（对称密钥））：
openssl enc -e -des3 -a -salt -in testfile -out testfile.cipher
解密：
openssl enc -d -des3 -a -salt –in testfile.cipher -out testfile
openssl ?
其中的：
-a 代表基于base64方式进行加密
-salt 会把加密结果进行打乱，即便相同的原数据只要盐不同，加密后的结果也不同
-e 代表加密
-d 代表解密
-in -out分别代表输入输出文件，-out也可以用输出重定向
-des3 代表3DES的加密算法，其他更多查看帮助

base64解释：

base64只是一种编码机制，类似ascii，它不是加密算法。它是把常见的字符转换为64个对应字符。
它的目的就是把加密的结果（包含很多不可见字符等等，会是乱码的格式）转为这64个可见的字符的形式来保存下来，这样利于管理和查看保存。（当然不仅仅可用于加密，还可以用于其他）
base64是把原始数据按照3个字节（24bit) 转换为4个字符（每个字符6bit，刚好是2^6=64个字符）的方式。
- 原始的数据是按照ascii的方式，每个字符占8bit，包括许多不可打印字符等等，会乱码
- 转换后的数据按照每个字符占6bit进行转换为64个可打印字符
- 如果原始的数据最后的部分不足以凑成3个字节（24bit)，则将会以0来补位，而每一个补位的6bit的0在base64中将会以=来表示，它代表这些0并不是原始数据中的，而是补位补出来的。
linux中用base64命令即可进行转换，base64 -d可以进行反解码，例如：

15:59[root@centos7 /data]# echo ab | base64
YWIK
15:59[root@centos7 /data]# echo -n ab | base64
YWI=
15:59[root@centos7 /data]# echo -n A | base64
QQ==
分析1：
ab : 01100001 01100010
补0并分成6个bit一位： 011000 010110 001000 000000 ：即为YWI=
分析2，因为含有\n这个符号，ascii中为00001010
ab\n: 01100001 01100010 00001010
不用补0，直接分成4个6bit字符：011000 010110 001000 001010 ：即为YWIK

反解码：
ab16:33[root@centos7 /boot/grub2]# echo -n YWI= |base64 -d
ab16:34[root@centos7 /boot/grub2]# echo -n YWIK |base64 -d
ab
16:34[root@centos7 /boot/grub2]#

openssl命令2

单向加密：

工具：md5sum, sha1sum, sha224sum,sha256sum…

16:09[root@centos7 /data]# sha512sum 11.t > 11.t.sha512
16:09[root@centos7 /data]# sha512sum -c 11.t.sha512
11.t: OK

openssl dgst（hash运算，需指定运算算法）

dgst命令：
帮助：man dgst
openssl dgst -md5 [-hex默认] /PATH/SOMEFILE
openssl dgst -md5 testfile
md5sum /PATH/TO/SOMEFILE
以上两个命令结果相同，格式略有不同
MAC: Message Authentication Code，单向加密的一种延伸应用，用于实现网络通信中保证所传输数据的完整性机制
CBC-MAC
HMAC：使用md5或sha1算法，已过时

生成用户密码：

passwd命令:
帮助：man sslpasswd
openssl passwd -1 -salt SALT(最多8位)
openssl passwd -1 –salt centos

其中-1代表md5 -salt后面可指定盐，当盐一样的时候，输入的密码如果一样则加密后的结果也会一样（盐不一样则密码一样加密后的结果也不一样）。

生成随机数：

帮助：man sslrand
openssl rand -base64|-hex NUM
NUM: 表示字节数，使用-hex，每个字符为十六进制，相当于4位二进制，出现的字符数为NUM*2
例子： openssl rand -base64 9 (只要是3的倍数就不会带=号。可当做口令用)

注意点3：

centos6中可用grub-crypt 来生成$6的加密密码用于其他地方，centos7中没有可以直接生成密码的命令了，只能grub2-setpasswd并把它放到文件里去了。
利用openssl rand -base64 3的倍数的方式生成随机数当做密码，然后再对其进行加密即可。

openssl生成公私钥等命令

公钥加密：
算法：RSA, ELGamal
工具：gpg, openssl rsautl（man rsautl）
数字签名：
算法：RSA, DSA, ELGamal
密钥交换：
算法：dh
DSA：Digital Signature Algorithm
DSS：Digital Signature Standard
RSA：

生成

生成密钥对儿：man genrsa
生成私钥
openssl genrsa -out /PATH/TO/PRIVATEKEY.FILE NUM_BITS
例子：(umask 077; openssl genrsa –out test.key –des3 2048)
其中小括号是在子进程中设置umask不影响当前shell,将生成的私钥修改权限。
openssl rsa -in test.key –out test2.key 将加密的key解密
从私钥中提取出公钥
openssl rsa -in PRIVATEKEYFILE –pubout –out PUBLICKEYFILE
例子：openssl rsa –in test.key –pubout –out test.key.pub

注意点4：

可以生成私钥之后再修改权限，或者用小括号生成的时候直接修改也可
生成私钥的时候 -out代表生成的文件，-des3 代表对私钥文件再次进行一次加密并利用des3算法（也可其他算法，查看帮助），后面的数字代表私钥的长度，默认512，注意这个必须是放在最后一个参数（1024,2048,4096）
2.2 如果创建的时候没有加密，则可以再用openssl enc对其再次进行加密以保证私钥的安全。
公钥是在私钥生成之后从私钥中计算（提取）出来的，当然不能反过来提取。

随机数生成器：伪随机数字

键盘和鼠标，块设备中断
/dev/random：仅从熵池返回随机数；随机数用尽，阻塞（表现为卡住，速度慢，可动动鼠标等继续生成）
/dev/urandom：从熵池返回随机数；随机数用尽，会利用软件生成伪随机数,非阻塞

OpenSSL生成和颁发证书

PKI：Public Key Infrastructure
CA
RA
CRL
证书存取库
建立私有CA:
OpenCA
openssl
证书申请及签署步骤：
1、生成申请请求
2、 RA核验
3、 CA签署
4、获取证书

创建CA和申请证书

创建私有CA：
openssl的配置文件：/etc/pki/tls/openssl.cnf
三种策略：match匹配、 optional可选、 supplied提供
match：要求申请填写的信息跟CA设置信息必须一致
optional：可有可无，跟CA设置信息可不一致
supplied：必须填写这项申请信息

创建所需要的文件
touch /etc/pki/CA/index.txt 生成证书索引数据库文件
echo 01 > /etc/pki/CA/serial 指定第一个颁发证书的序列号
CA自签证书
生成私钥
cd /etc/pki/CA/
(umask 066; openssl genrsa -out private/cakey.pem 2048)
生成自签名证书
openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -days 3650 -out /etc/pki/CA/cacert.pem
选项说明：
-new：生成新证书签署请求
-x509：专用于CA生成自签证书
-key：生成请求时用到的私钥文件
-days n：证书的有效期限
-out /PATH/TO/SOMECERTFILE: 证书的保存路径
- 附加：查看证书中的信息：
  openssl x509 -in /PATH/FROM/CERT_FILE -noout -text|issuer|subject|serial|dates
  openssl ca -status SERIAL 查看指定编号的证书状态
颁发证书：在需要使用证书的主机生成证书请求
- 给web服务器生成私钥：
  (umask 066; openssl genrsa –out /data/test.key 2048)
  注意上一步生成的密钥一般存放在需要证书的服务或者软件目录下（/data/app/)
- 生成证书申请文件：
  openssl req -new -key /data/test.key -out /data/test.csr
- 将证书请求文件传输给CA（scp到/tmp/test.csr）
- CA审核签署证书，并将证书颁发给请求者（必须要存在第一步所写的两个文件，同时serial文件中还得有编号）
  openssl ca -in /tmp/test.csr –out /etc/pki/CA/certs/test.crt -days 100
- 注意：默认要求国家，省，公司名称三项必须和CA一致,这三项分别为第1、2、4项在申请证书的需要填写的信息（也可更改默认policy全部不需要匹配）
吊销证书
- 在客户端获取要吊销的证书的serial
  openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject
- 在CA上，根据客户提交的serial与subject信息，对比检验是否与index.txt文件中的信息一致，
  然后吊销证书：
  openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem
- 指定第一个吊销证书的编号,注意：第一次更新证书吊销列表前，才需要执行
  echo 01 > /etc/pki/CA/crlnumber
- 更新证书吊销列表
  openssl ca -gencrl -out /etc/pki/CA/crl.pem
- 查看crl文件：
  openssl crl -in /etc/pki/CA/crl.pem -noout -text

注意点5：

第一步中的两个文件必须要存在，且序列号必须要指定才能够审核颁发证书
policy默认要匹配颁发证书时的第1/2/4项目，而第3567项没要求。
注意要严格按照下面的名称和位置目录来生成和颁发证书。
- 当颁发一个新的证书的时候，index.txt文件中就会生成一个对应的表项来进行记录，可用cat查看
- 同时，颁发一个新证书的时候，newcerts中会与certs中有相同的证书文件，只不过newcerts中是自动生成的证书文件，certs中是命令指定生成在此目录下的证书。并且newcets中的证书文件是按照证书的序列号来命名的。
证书申请完毕之后便可以将证书拷贝给用户以供服务和程序使用（以后再细说）
如果对一个证书申请文件csr再次颁发第二个证书，默认不允许会失败（因为两个证书申请文件的subject也就是申请时填写的信息完全一致，会被认为有问题），不过如果修改了/etc/pki/CA/index.txt.attr文件中的unique_subject = yes 改为no的话，这就可以对同一个证书申请文件多次颁发证书了。
在CA上吊销一个证书要利用的文件目录是newcerts，而并非是生成的时候命令中所写的certs目录中。
- 同时吊销了一个证书必须要放在吊销列表中发布公告，因此吊销之前要生成这个吊销列表的编号文件（类似生成证书的列表，需要注意的是，吊销列表的编号和生成列表的证书的编号不需要对应关系。生成的证书的serial会在吊销列表的每一项中的数据信息中，而不是在吊销列表的serial编号中，所以它俩并无关联）。注意只有第一次更新吊销列表之前才需要执行
- 生成了吊销列表的编号文件，并吊销了证书之后便可以更新吊销列表了（它类似生成证书的数据库文件index.txt和cert目录中的证书文件的合体文件）,此时更新便不会报错（如果没有生成编号文件会报错），然后便可以查看它了。具体参考上面的命令

参考下面的目录和信息来创建CA和颁布证书等：

[ ca ]
default_ca      = CA_default            # The default ca section

[ CA_default ]

dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept ：证书的文件存放位置
crl_dir         = $dir/crl              # Where the issued crl are kept :证书吊销列表存放目录
database        = $dir/index.txt        # database index file.  ：证书颁发的用户（包括用户名，有效期，状态等）的列表数据库
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs. ：默认颁发的新的证书的位置

certificate     = $dir/cacert.pem       # The CA certificate ：CA自己的证书
serial          = $dir/serial           # The current serial number ：证书的编号，它表示下一个要颁发给用户的证书的编号
crlnumber       = $dir/crlnumber        # the current crl number ：证书吊销列表的编号
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL  ：证书吊销列表生成的文件
private_key     = $dir/private/cakey.pem# The private key ：CA的私钥
RANDFILE        = $dir/private/.rand    # private random number file ：随机数文件

x509_extensions = usr_cert              # The extentions to add to the cert ：证书标准格式

default_days    = 365                   # how long to certify for ：默认证书有效期
default_crl_days= 30                    # how long before next CRL ：默认证书吊销列表有效期
default_md      = sha256                # use SHA-256 by default ：默认加密算法
preserve        = no                    # keep passed DN ordering

policy          = policy_match 
：它定义了用户申请证书的时候，所要填写的信息中，哪些与CA自身的证书的项目必须一致，才会给此申请者颁发证书。否则不颁发（有点类似生活中不同地区的户籍管理必须找当地的政府派出所等，不能去其它地方的管理部门）
：下面的每项都可自己定义更改，同时上面的policy也可在不同情况下分别更换不同的policy。
# For the CA policy
[ policy_match ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

转载于:https://blog.51cto.com/14228129/2384475

weixin_34319640

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
22.加密与安全相关,证书申请CA（gpg，openssl)

安全机制信息安全防护的目标保密性 Confidentiality完整性 Integrity可用性 Usability可控制性 Controlability不可否认性 Non-repudiation安全防护环节物理安全：各种设备/主机、机房环境系统安全：主机或设备的操作系统应用安全：各种网络服务、应用程序网络安全：对网络访问的控制、防火墙规则数据安全：信息的备份与恢复、加密解密管理安全：各种保...
复制链接

扫一扫