1. 证书
1.1 证书的应用场景
1.2 证书规范和格式 -- x509
1.3 CA证书
证书的获取和身份的认证
客户端如何验证CA证书是可信任的?
有哪些CA机构?
1.4 公钥基础设施 - PKI
- PKI组成的要素
- 用户
- 申请证书的人 -> web服务器端
- 申请证书
- 生成密钥对 , 或者委托ca生成
- 将公钥发送给CA
- ca使用自己的私钥对得到公钥签名
- 将证书发送给用户
- 发送证书
- 当客户端访问服务器的时候发送证书给客户端
- 注销证书
- 当发现私钥泄露之后
- 申请证书
- 使用证书的人 -> 客户端
- 接收证书
- 验证对方的身份信息
- 申请证书的人 -> web服务器端
- CA认证机构
- 可以生产密钥对(可选)
- 对公钥签名
- 吊销证书
- 仓库
- 存储证书 -> 公钥
- 用户
2. SSL/TLS
描述的是客户端和服务器刚建立连接之后做的事情
第一次
- 客户端连接服务器
- 客户端使用的ssl版本, 客户端支持的加密算法
- 服务器
- 先将自己支持ssl版本和客户端的支持的版本比较
- 支持的不一样, 连接断开
- 支持的一样, 继续
- 根据得到的客户端支持 的加密算法, 找一个服务器端也同样支持算法, 发送给客户端
- 需要发送服务器的证书给客户端
- 先将自己支持ssl版本和客户端的支持的版本比较
第二次:
客户端:
- 接收服务器的证书
- 校验证书的信息
- 校验证书的签发机构
- 证书的有效期
- 证书中支持 的域名和访问的域名是否一致
- 校验有问题, 浏览器会给提示
- 客户端连接服务器
3. https -> 单向认证
- 服务器要准备的
- 生成密钥对
- 将公钥发送给ca, 由ca签发证书
- 将ca签发的证书和非对称加密的私钥部署到当前的web服务器
- 通信流程
- 客户端连接服务器, 通过一个域名
- 域名和IP地址的关系
- 域名要绑定IP地址
- 一个域名只能绑定一个IP地址
- IP地址需要被域名绑定
- 一个IP地址可以被多个域名绑定
- 域名要绑定IP地址
- 客户端访问的域名会别解析成IP地址, 通过IP地址访问web服务器
- 域名和IP地址的关系
- 服务器收到了客户端的请求
- 服务器将CA签发的证书发送给浏览器(客户端)
- 客户端拿到了服务器的公钥证书
- 读这个公钥 证书
- 验证域名
- 有效期
- ca签发机构
- 服务器的公钥
- 读这个公钥 证书
- 客户会生成一个随机数 (作为对称加密的秘钥来使用的)
- 使用服务器的公钥就这个随机数进行加密
- 将这个加密之后 秘钥发送给服务器
- 服务器对收到的密文解密
- 使用服务器的是要解密, 得到对称加密的秘钥
- 数据的传输
- 使用对称加密的方式对数据进行加密
- 客户端连接服务器, 通过一个域名
4. 自签名证书
使用openssl生成自签名证书
创建一个目录如Mytest, 进入该目录, 在该目录下打开命令行窗口
启动openssl
openssl # 执行该命令即可使用openssl工具生成一个RSA私钥, 注意：生成私钥，需要提供一个至少4位的密码。
genrsa -des3 -out server.key 2048 - des3: 使用3des对私钥进行加密生成CSR（证书签名请求）
req -new -key server.key -out server.csr删除私钥中的密码, 第一步给私钥文件设置密码是必须要做的, 如果不想要可以删掉
rsa -in server.key -out server.key -out 参数后的文件名可以随意起生成自签名证书
x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
复习
消息认证码
- 是什么?
- 散列值
- 能干什么?
- 保证数据的完整性, 一致性
- 怎么生成?
- 准备的条件: Hmac
- 原始数据
- 共享秘钥 -> 认证的另一方需要有同样的秘钥
- 哈希算法
- 准备的条件: Hmac
- 弊端:
- 秘钥分发困难
- 使用非对称加密
- 不能第三方认证
- 不能防止否认
- 秘钥分发困难
- 是什么?
数字签名
是什么?
- 签名
- 签名的人生成非对称加密的密钥对
- 签名的人将公钥进行分发
- 签名的人将原始数据进行哈希运算 -> 散列值
- 签名的人使用自己的私钥对散列值进行非对称加密 -> 最终得到的数据就是签名
- 校验:
- 接收签名人的公钥
- 接收签名人发送的数据和签名数据
- 对原始数据进行哈希运算 -> 散列值
- 使用公钥对签名数据解密
- 将解密出的数据和散列值进行比较
- 相等 == 成功
- 不.. == 失败
- 签名
干什么?
- 保证数据的一致性
- 进行第三方认证
- 可以防止否认
能解决消息认证的弊端吗?
- 可以
怎么进行签名
RSA
椭圆曲线签名 -> ecdsa
数字签名的缺陷?
- 验证签名的一方没有办法判断得到的公钥到底属于谁
8. 证书
"证书 -- 为公钥加上数字签名"8.1 证书的应用场景
- 认证机构Trent用自己的私钥对Bob的公钥施加数字签名并生成证书
Trent对Bob的公钥加上数字签名。为了生成数字签名，需要Trent自身的私钥，因此Trent需要事先生成好密钥对。
- Alice得到带有认证机构Trent的数字签名的Bob的公钥（证书）
现在Alice需要向Bob发送密文，因此她从Trent处获取证书。证书中包含了Bob的公钥。
- Alice使用认证机构Trent的公钥验证数字签名，确认Bob的公钥的合法性
Alice使用认证机构Trent的公钥对证书中的数字签名进行验证。如果验证成功，就相当于确认了证书中所包含的公钥的确是属于Bob的。到这里，Alice就得到了合法的Bob的公钥。
- Alice用Bob的公钥加密消息并发送给Bob
Alice用Bob的公钥加密要发送的消息，并将消息发送给Bob。
- Bob用自己的私钥解密密文得到Alice的消息
Bob收到Alice发送的密文，然后用自己的私钥解密，这样就能够看到Alice的消息了。
上面就是利用认证机构Trent进行公钥密码通信的流程。其中1、2、3这几个步骤仅在注册新公钥时才会进行，并不是每次通信都需要。此外，步骤 4 仅在Alice第一次用公钥密码向Bob发送消息时才需要进行，只要Alice将Bob的公钥保存在电脑中，在以后的通信中就可以直接使用了。
8.2 证书标准规范X.509
8.2.1 证书规范
8.2.2 证书格式
-----BEGIN CERTIFICATE-----
MIIDyjCCArKgAwIBAgIQdZfkKrISoINLporOrZLXPTANBgkqhkiG9w0BAQsFADBn
MSswKQYDVQQLDCJDcmVhdGVkIGJ5IGh0dHA6Ly93d3cuZmlkZGxlcjIuY29tMRUw
EwYDVQQKDAxET19OT1RfVFJVU1QxITAfBgNVBAMMGERPX05PVF9UUlVTVF9GaWRk
bGVyUm9vdDAeFw0xNzA0MTExNjQ4MzhaFw0yMzA0MTExNjQ4MzhaMFoxKzApBgNV
BAsMIkNyZWF0ZWQgYnkgaHR0cDovL3d3dy5maWRkbGVyMi5jb20xFTATBgNVBAoM
DERPX05PVF9UUlVTVDEUMBIGA1UEAwwLKi5iYWlkdS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDX0AM198jxwRoKgwWsd9oj5vI0and9v9SB9Chl
gZEu6G9ZA0C7BucsBzJ2bl0Mf6qq0Iee1DfeydfEKyTmBKTafgb2DoQE3OHZjy0B
QTJrsOdf5s636W5gJp4f7CUYYA/3e1nxr/+AuG44Idlsi17TWodVKjsQhjzH+bK6
8ukQZyel1SgBeQOivzxXe0rhXzrocoeKZFmUxLkUpm+/mX1syDTdaCmQ6LT4KYYi
soKe4f+r2tLbUzPKxtk2F1v3ZLOjiRdzCOA27e5n88zdAFrCmMB4teG/azCSAH3g
Yb6vaAGaOnKyDLGunW51sSesWBpHceJnMfrhwxCjiv707JZtAgMBAAGjfzB9MA4G
A1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDATAWBgNVHREEDzANggsq
LmJhaWR1LmNvbTAfBgNVHSMEGDAWgBQ9UIffUQSuwWGOm+o74JffZJNadjAdBgNV
HQ4EFgQUQh8IksZqcMVmKrIibTHLbAgLRGgwDQYJKoZIhvcNAQELBQADggEBAC5Y
JndwXpm0W+9SUlQhAUSE9LZh+DzcSmlCWtBk+SKBwmAegbfNSf6CgCh0VY6iIhbn
GlszqgAOAqVMxAEDlR/YJTOlAUXFw8KICsWdvE01xtHqhk1tCK154Otci60Wu+tz
1t8999GPbJskecbRDGRDSA/gQGZJuL0rnmIuz3macSVn6tH7NwdoNeN68Uj3Qyt5
orYv1IFm8t55224ga8ac1y90hK4R5HcvN71aIjMKrikgynK0E+g45QypHRIe/z0S
/1W/6rqTgfN6OWc0c15hPeJbTtkntB5Fqd0sfsnKkW6jPsKQ+z/+vZ5XqzdlFupQ
29F14ei8ZHl9aLIHP5s=
-----END CERTIFICATE-----证书中的解析出来的内容：
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-G2
Validity
Not Before: Nov 21 08:00:00 2016 GMT
Not After : Nov 22 07:59:59 2017 GMT
Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
9d:3b:ef:d5:c1
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Agreement
Authority Information Access:
CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.4146.1.20
CPS: https://www.globalsign.com/repository/
Policy: 2.23.140.1.2.2
X509v3 Basic Constraints:
CA:FALSE
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
X509v3 Subject Alternative Name:
DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Key Identifier:
28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
X509v3 Authority Key Identifier:
keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
Signature Algorithm: sha256WithRSAEncryption
8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
...
8.2.3 CA证书
CA证书
证书信任链
证书有啥用
8.3 公钥基础设施（PKI）
8.3.1 什么是公钥基础设施
8.3.2 PKI的组成要素
PKI的组成要素主要有以下三个：
- 用户 --- 使用PKI的人
- 认证机构 --- 颁发证书的人
- 仓库 --- 保存证书的数据库
用户
注册公钥的用户所进行的操作
- 生成密钥对（也可以由认证机构生成）
- 在认证机构注册公钥
- 向认证机构申请证书
- 根据需要申请作废已注册的公钥
- 解密接收到的密文
- 对消息进行数字签名
使用已注册公钥的用户所进行的操作
- 将消息加密后发送给接收者
- 验证数字签名
/* ==================== 小知识点 ==================== 浏览器如何验证SSL证书 1. 在IE浏览器的菜单中点击“工具 /Internet选项”，选择“内容”标签，点击“证书”按钮，然后就可以看到IE 浏览器已经信任了许多“中级证书颁发机构”和“受信任的根证书颁发机 构。当我们在访问该网站时，浏览器 就会自动下载该网站的SSL证书，并对证书的安全性进行检查。 2. 由于证书是分等级的，网站拥有者可能从根证书颁发机构领到证书，也可能从根证书的下一级（如某个国家 的认证中心，或者是某个省发出的证书）领到证书。假设我们正在访问某个使用 了 SSL技术的网站，IE浏 览器就会收到了一个SSL证书，如果这个证书是由根证书颁发机构签发的，IE浏览器就会按照下面的步骤来 检查：浏览器使用内 置的根证书中的公钥来对收到的证书进行认证，如果一致，就表示该安全证书是由可信 任的颁证机构签发的，这个网站就是安全可靠的；如果该SSL证书不是根服 务器签发的，浏览器就会自动检 查上一级的发证机构，直到找到相应的根证书颁发机构，如果该根证书颁发机构是可信的，这个网站的SSL证 书也是可信的。 */
认证机构（CA）
生成密钥对 (也可以由用户生成)
在注册公钥时对本人身份进行认证, 生成并颁发证书
作废证书