安全机制
- 信息安全防御的目标
保密性 Confidentiality
完整性 Integrity
可用性 Usability
可控制性 Controlability
不能否认性 Non-repudiation
- 安全防御环节
物理安全:各类设备/主机、机房环境
系统安全:主机或设备的操做系统
应用安全:各类网络服务、应用程序
网络安全:对网络访问的控制、防火墙规则
数据安全:信息的备份与恢复、加密解密
管理安全:各类保障性的规范、流程、方法
安全***: STRIDE
Spoofing 假冒
Tampering 篡改
Repudiation 否定
Information Disclosure 信息泄漏
Denial of Service 拒绝服务
Elevation of Privilege 提高权限linux
- 其中拒绝服务是比较难以防止的,对方可使用高流量致使网络瘫痪,以及IP更换等手段防止被禁。
安全设计基本原则
使用成熟的安全系统
以小人之心度输入数据
外部系统是不安全的
最小受权
减小外部接口
缺省使用安全模式
安全不是似是而非
从STRIDE思考
在入口处检查
从管理上保护好你的系统git
安全算法
- 经常使用安全技术
认证:密码,生物指纹,虹膜等
受权
审计
安全通讯
- 加密算法和协议
对称加密
公钥加密
单向加密
认证协议
对称加密算法
- 对称加密:加密和解密使用同一个密钥
DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5
- 特性:
一、加密、解密使用同一个密钥,效率高
二、将原始数据分割成固定大小的块,逐个进行加密
- 缺陷:
一、密钥过多
二、密钥分发:密钥在双方的传输过程当中容易被偷取
三、数据来源没法确认:没法确认数据是不是真正的发送方发送
非对称加密算法
- 公钥加密:密钥是成对出现
公钥:公开给全部人;public key
私钥:本身留存,必须保证其私密性;secret key
- 特色:用公钥加密数据,只能使用与之配对的私钥解密;反之亦然
- 功能:
数字签名:主要在于让接收方确认发送方身份(利用发送方的私钥加密部分数据,好比加密)
对称密钥交换:发送方用对方的公钥加密一个对称密钥后发送给对方
数据加密:适合加密较小数据
- 缺点:密钥长,加密解密效率低下
- 算法:
RSA(既能够加密,也可数字签名)
DSA(只能数字签名)
ELGamal
非对称加密
单向散列(哈希算法)
- 将任意数据缩小成固定大小的“指纹”
任意长度输入
固定长度输出
若修改数据,指纹也会改变(“不会产生冲突”)
若数据同样,则指纹也相同
没法从指纹中从新生成数据(“单向不可逆”)
- 功能:数据完整性,能够把结果和与原数据看作是相互一一对应的映射
- 常见算法
md5: 128bits、 sha1: 160bits、 sha22四、 sha25六、 sha38四、 sha512
- 经常使用工具和命令:
md5sum | sha1sum [ --check ] file :还有sha512sum等等
openssl、 gpg
rpm -V
数字签名:将hash计算以后的结果摘要利用私钥加密以后便被称为数字签名。

示例应用程序: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 )主要有如下两种方式:shell
- 公钥加密密钥,而后私钥解密密钥,达到传输的效果(参考上面的过程)
- 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主机上解密
- 在hostA主机上生成公钥/私钥对
gpg --gen-key
- 在hostA主机上查看公钥
gpg --list-keys
- 在hostA主机上导出公钥到zhanga.pubkey
gpg -a --export -o zhanga.pubkey
- 从hostA主机上复制公钥文件到需加密的B主机上
scp zhanga.pubkey hostB:
- 在需加密数据的hostB主机上生成公钥/私钥对
gpg --list-keys
gpg --gen-key
- 在hostB主机上导入公钥
gpg --import zhanga.pubkey
gpg --list-keys
- 在hostB上用导入的hostA的公钥,加密hostB主机的文件file,生成file.gpg:注意加密的时候不要写错所用的公钥了
gpg -e -r zhanga file
file file.gpg
- 复制加密文件到hostA主机
scp fstab.gpg hostA:
- 在hostA主机解密文件
gpg -d file.gpg
gpg -o file -d file.gpg
- 删除公钥和私钥(写上对应的名字)
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分发点
扩展信息
发行者签名
证书获取
- 证书类型:
证书受权机构的证书
服务器
用户证书
- 获取证书两种方法:
- 使用证书受权机构
生成证书请求(csr文件)
将证书请求csr文件发送给CA
CA签名颁发证书
- 自签名的证书
自已签发本身的公钥
注意点2:
-
证书申请方向证书颁发受权机构发送本身的信息以及公钥,申请证书。证书颁发受权机构CA 利用本身的私钥对证书申请方的各类信息进行加密并按照必定格式(参考上面所写)颁发证书,包含着此证书颁发机构的签名等。centos
- 而后证书申请人拿到证书以后即可以将它发送给须要交流通信的其余目标方,这些目标方根据此证书的颁发机构的公钥来解密此证书,即可以获得证书申请人的各类信息包括它的公钥信息
- 同理这些目标方也可申请证书并发送给他人,这样双方就实现了本身的信息以及公钥的交换,保证了公钥交换过程的安全性。
- 经过这种第三方颁发证书的方式来解决了最后一个的公钥交换的安全和来源确认问题。
-
而证书颁发机构不必定是一个。多个不一样的证书颁发机构的证书申请方之间的相互通信过程是这样的:安全
- 好比说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
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
- 证书申请及签署步骤:
一、生成申请请求
二、 RA核验
三、 CA签署
四、获取证书
建立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一致,这三项分别为第一、二、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