HTTP协议介绍
一般使用80端口
HTTPS协议介绍
一般使用443端口
SSL/TLS协议基本原理
将公钥放在数字证书中，只要证书是可信的，公钥就是可信的
- 客户端向服务器端索要证书并验证公钥。
- 双方协商生成”对话密钥(对称加密)”。
- 双方采用”对话密钥(对称加密)”进行加密通信。
HTTPS工作步骤
- 客户端发起HTTPS请求
- 服务端的配置(申请证书，或者自己制作)
- 传送证书(证书包含公钥)
- 客户端解析证书(校验，读取公钥)
- 传送加密信息(用证书加密后的随机值,后续通过这个随机值生成新密钥进行加密解密)
- 服务端解密信息(服务端用私钥解密后，得到了客户端传过来的随机值,然后把内容通过该值进行对称加密)
- 传输加密后的信息(加密后的信息，可以在客户端被还原)
- 客户端解密信息(用通过随机码生成的密钥解密)
证书介绍
为了验证对方的身份，避免黑客伪造对方身份进行通信。
根证书：是指CA机构颁发SSL证书的核心，是信任链的起始点。根证书是浏览器是否对SSL证书每个浏览器都有一个根证书库，而根证书库是下载客户端浏览器时预先加载根证书的合集。其实当客户端访问服务器时，浏览器会查看SSL证书并执行快速验证SSL证书的真实性。因此根证书是十分重要的，因为它可确保浏览器自动信任已使用私钥签名的SSL证书。
操作系统能信任根证书颁发机构，也就可以信任被根证书颁发机构信任的公司，进而可以信任被这些公司所信任的下一级公司。
用户在获取SSL证书之前，首先要生成证书签名请求（CSR）和私钥。在最简单的迭代中，用户将生成的CSR发生到证书颁发机构，然后使用CA机构的根证书的私钥签署用户的SSL证书，并将SSL证书发回给用户。当浏览器检测到SSL证书时，就会查看证书是由其中一个受信任的根证书签名（使用root的私钥签名）。由于浏览器信任root，所以浏览器也信任根证书签名的任何证书。
CA 即证书授权中心（CA, Certificate Authority）。CA是负责签发证书、认证证书、管理已颁发证书的机关。用户向CA提出申请后，CA负责审核用户信息，然后对关键信息利用私钥进行”签名”，并公开对应的公钥。客户端可以利用公钥验证签名。
CSR（Certificate Signing Request）即证书请求文件，也就是证书申请者在申请数字证书时由CSP（加密服务提供者）在生成私钥的同时也生成证书请求文件，证书申请者只要把CSR文件提交给证书颁发机构后，证书颁发机构使用其根证书私钥签名就生成了证书公钥文件，也就是颁发给用户的证书。
证书生成工具openssl
文件格式
.key格式：私密
.csr格式：证书签名请求（证书请求文件），含有公钥信息
.crt格式：证书文件，certificate的缩写。是CA认证后的证书文件，签署人用自己的key给你签署的凭证
.crl格式：证书吊销列表，Certificate Revocation List的缩写
.pem格式：用于导出，导入证书时候的证书的格式，有证书开头结尾的格式
命令说明
1 | ca 签发证书命令 |
生成根证书
- 生成RSA私钥
openssl genrsa -out private_key.pem 2048 - 生成证书请求
openssl req -new -key private_key.pem -out ca.pem - 签发自签名证书
openssl x509 -in ca.pem -req -signkey private_key.pem -days 888 -out cert.pem
生成用户证书
- 生成RSA私钥
openssl genrsa -out cli_private_key.pem 2048 - 生成证书
openssl req -new -key cli_private_key.pem -out cli_ca.pem - 签发证书
openssl x509 -in cli_ca.pem -req -CA cert.pem -CAkey private_key.pem -days 888 -set_serial 01 -out cli_cert.pem
证书格式转换
- der格式证书转pem格式
openssl x509 -inform der -in cert.cer -out cert.pem - pem到der
openssl x509 -in name.pem -outform der -out xxx.cer
内容查看，也可以当格式校验用
- 查看DER证书
openssl x509 -in xxx.cer -inform der -text -noout - 查看PEM证书
openssl x509 -in xxx.pem -text -noout
tomcat证书生成-使用jdk自带的keytool生成
tomcat证书生成-通过openssl生成
一、建立目录
1 | cd /home |
创建一个证书的步骤：
（1）生成系统私钥(.key)
（2）生成证书请求(.csr)
（3）生成x509证书, 用CA私钥进行签名(.crt)
（4）导成浏览器支持的p12格式证书
二：生成CA证书
目前不使用第三方权威机构的CA来认证，自己充当CA的角色。
- 创建私钥
openssl genrsa -out ca/ca-key.pem 1024 - 创建证书：
openssl req -new -out ca/ca-req.csr -key ca/ca-key.pem
输入一些基础信息 - 自签署证书(通过ca私钥生成ca证书) ：
openssl x509 -req -in ca/ca-req.csr -out ca/ca-cert.pem -signkey ca/ca-key.pem -days 3650 - 将证书导出成浏览器支持的.p12格式 ：
openssl pkcs12 -export -clcerts -in ca/ca-cert.pem -inkey ca/ca-key.pem -out ca/ca.p12
密码：123456
三.生成server证书
创建私钥 ：
openssl genrsa -out server/server-key.pem 1024创建证书请求 ：
openssl req -new -out server/server-req.csr -key server/server-key.pemCommon Name (eg, YOUR name) []:localhost #此处要写服务器所在ip
A challenge password []:123456自签署证书(提供csr文件，通过ca的私钥生成，-signkey是自签名密钥) ：
openssl x509 -req -in server/server-req.csr -out server/server-cert.pem -signkey server/server-key.pem -CA ca/ca-cert.pem -CAkey ca/ca-key.pem -CAcreateserial -days 3650将证书导出成浏览器支持的.p12格式 ：
openssl pkcs12 -export -clcerts -in server/server-cert.pem -inkey server/server-key.pem -out server/server.p12
密码：123456
四.生成client证书
创建私钥 ：
openssl genrsa -out client/client-key.pem 1024创建证书请求 ：
openssl req -new -out client/client-req.csr -key client/client-key.pem
录入详情
Country Name (2 letter code) [AU]:cn
State or Province Name (full name) [Some-State]:bj
Locality Name (eg, city) []:bj
Organization Name (eg, company) [Internet Widgits Pty Ltd]:it
Organizational Unit Name (eg, section) []:it
Common Name (eg, YOUR name) []:a
Email Address []:a@infotech.vipPlease enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:123456
An optional company name []:自签署证书(通过ca的私钥生成，-signkey是自签名密钥) ：
openssl x509 -req -in client/client-req.csr -out client/client-cert.pem -signkey client/client-key.pem -CA ca/ca-cert.pem -CAkey ca/ca-key.pem -CAcreateserial -days 3650将证书导出成浏览器支持的.p12格式 ：
openssl pkcs12 -export -clcerts -in client/client-cert.pem -inkey client/client-key.pem -out client/client.p12
密码：123456
五.根据ca证书生成jks文件 (java keystore)
keytool -keystore truststore.jks -keypass 222222 -storepass 222222 -alias ca -import -trustcacerts -file ca/ca-cert.pem
六.配置tomcat ssl
修改conf/server.xml。tomcat6中多了SSLEnabled=”true”属性。keystorefile, truststorefile设置为你正确的相关路径
xml 代码
tomcat6.0的配置：
1 | <Connector port="7443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" keystoreFile="/home/ssl/server/server.p12" keystorePass="123456" keystoreType="PKCS12" truststoreFile="/home/ssl/truststore.jks" truststorePass="222222" truststoreType="JKS"/> |
七、测试（linux下）
openssl s_client -connect localhost:7443 -cert /home/ssl/client/client-cert.pem -key /home/ssl/client/client-key.pem -tls1 -CAfile /home/ssl/ca/ca-cert.pem -state -showcerts
八、导入证书
服务端导入server.P12 和ca.p12证书
客户端导入将ca.p12，client.p12证书,下载到PC机可以双击导入
IE中（打开IE->;Internet选项->内容->证书）
ca.p12导入至受信任的根证书颁发机构，client.p12导入至个人
Firefox中（工具-选项-高级-加密-查看证书-您的证书）
将ca.p12和client.p12均导入这里
注意:ca,server,client的证书的common name(ca=ca,server=localhost,client=dong)一定不能重复，否则ssl不成功
九、tomcat应用程序使用浏览器证书认证-非必要
在server/webapps/manager/WEB-INF/web.xml中，将BASIC认证改为证书认证
1 | <login-config> |
在conf/tomcat-users.xml中填入下列内容
1 |
|
自己建一个工程访问或者：
访问http://localhost:7443即可验证ssl是否成功
访问http://localhost:7443/manager/html可验证应用程序利用client证书验证是否成功
证书卸载
windows系统 win+R 输入 certmgr.msc，在个人里面
证书校验
一：首先浏览器通过URL网址去请求服务端，服务端接收到请求后，就会给浏览器发送一个自己的CA数字证书
二：浏览器接收到证书以后，就要开始进行验证工作了。首先从证书中得知证书的颁发机构，然后从浏览器系统中去寻找此颁发机构的根证书。
证书中可以看到有一个叫指纹的字符串，指纹可以理解为证书身份的唯一代表，是用来保证证书的完整性的，确保证书没有被修改过。证书在发布之前，CA机构对证书的内容用指纹算法（一般是sha1或sha256）计算得到一个hash值，这个hash值就是指纹。签名是在信息后面加上的一段数字串，可以证明该信息有没有被修改过。数字证书在发布的时候，CA机构将证书的指纹和指纹算法通过自己的私钥加密得到的就是证书的签名了。先简单阐述一下证书的指纹和签名的作用，我们在验证证书的时候，首先通过机构的根公钥去解密证书的签名，解密成功的话会得到证书的指纹和指纹算法，指纹是一个hash值，它代表着证书的原始内容，此时再通过指纹算法计算证书内容得到另外一个hash值，如果这两个hash值相同，则代表证书没有被篡改过，否则就是被篡改了。
如果我们找到了证书颁发机构的根证书，那么就从根证书中取得那个根公钥，用根公钥去解密此证书的数字签名，成功解密的话就得到证书的指纹和指纹算法，指纹是证书内容通过指纹算法计算得到的一个hash值，这里我们称之为h1，h1代表证书的原始内容（是代表，不是真正的原始内容，hash了是不可逆的）；然后用指纹算法对当前接收到的证书内容再进行一次hash计算得到另一个值h2，h2则代表当前证书的内容，如果此时h1和h2是相等的，就代表证书没有被修改过。如果证书被篡改过，h2和h1是不可能相同的，因为hash值具有唯一性，不同内容通过hash计算得到的值是不可能相同的。如证书上的指纹是不法分子伪造的，伪造是没有用的，因为你伪造的指纹不可能用CA机构的根私钥去加密（根私钥是CA机构绝对保密的），伪造者只能拿自己的秘钥去加密这个伪造的指纹，但当我们拿机构的根公钥去解密伪造指纹的时候是不可能成功的（加密内容只能由一对公钥私钥解密）
在证书没有被修改过的基础上，再检查证书上的使用者的URL（比如baidu.com）和我们请求的URL是否相等，如果相等，那么就可以证明当前浏览器链接的网址也是正确的，而不是一些钓鱼网之类的。
但如果浏览器的连接被某个中间人截取了，中间人也可以发一个由权威的CA机构颁发的证书给浏览器，然后也可以通过证书没有被篡改的验证，但是在证书没有被篡改的前提下，通过对比证书上的URL和我们请求的URL是否相同，我们还是可以判断当前证书是不是服务器发的证书。可以这么理解，因为URL具有唯一性，所以中间人的证书的上的URL和我们的证书的URL是不可能相同的，如果中间人修改了自己证书上的URL，那么就通过不了证书没有被篡改的验证，所以中间人的证书也是欺骗不了我们的。所以Fidder工具中每次都要生成一个域名的证书，需要我们手动信任签发机构才会被截取解析出来。
到这里我们认证了三点信息：
1.证书是否为受信任的权威机构颁发的
2.证书是否被篡改
3.证书是否为服务器发过来的，而不是第三方发的
三：基于上面的三点信息认证都没有问题的情况下，下一步我们有一个重要的任务就是，如何将一个对称加密算法的秘钥安全地发给服务器
首先随机生成一个字符串S作为我们的秘钥，然后通过证书公钥加密成密文，将密文发送给服务器。因为此密文是用公钥加密的，这是一个非对称加密，我们知道，这个密文只有私钥的持有者才能进行解密，在这里私钥的持有者当然是服务器了，所以说任何第三方截取到密文也是没用的，因为没有对应的私钥无法解密得到我们的密文。
还有一个关键步骤，发送密文的时候也会对消息内容进行签名操作。签名上面讲解过，就是对密文内容进行hash计算得到的hash值再通过公钥或私钥加密得到的一段数字串，这个签名和消息内容一起发送出去。接收方收到消息以后，通过私钥或公钥解析出密文和签名的hash值，同时也会对接收的消息内容进行同样的hash计算得到另一个hash值，比对两个hash值是否相同来判断消息有没有被篡改过。想要篡改怎么办？必须有私钥才能篡改，用这个机构签发的其他证书改也是不可行的，证书内容没办法改变。
四：通过了上面的步骤以后，此时客户端和服务端都持有了对称加密算法的同一个秘钥，然后兄弟俩就可以愉快地安全通信了。
hash值具有不可逆性，也就是说无法通过hash值得出原来的信息内容；其次，hash值具有唯一性，即hash计算可以保证不同的内容一定得到不同的hash值。
client拿到证书，检验颁发机构是否可信。若可信，它会用公钥解密数字签名，得到一个hash串A。
从Firefox/IE导出的数字证书包含3个部分：证书内容(F)，加密算法(A)，F加密密文(F’) ，在这里，A不是一个算法，而是两个，所以密文F’是F两次加密后的结果。当你要验证这个数字证书可信/合法性时，你需要找到你的上一层CA认证中心的数字证书，并且从中获取公钥，把数据证书中的密文F’进行RSA解密，如果得出的值h2和h1比较（h1可以立即用数据证书中的F经过SHA1算出来），如果相等，则认为证书是可信的，合法的！
证书发布者： 证书内容 → SHA1加密 → RSA加密 → 证书数字签名
验证证书者： 证书数字签名 → RSA解密(公钥) → H2
证书内容 → SHA1加密 → H1
H1等于H2说明校验通过
1.Certificate(证书)：
(1).Common Name(证书所有人姓名，简称CN，其实就是证书的名字，如第一幅图看到的：ABA.ECOMRoot….)
(2).Version(版本，现在一般是V3了)
(3).Issuer(发证机关)
(4).Validity(有效日期)
(5).Subject(证书信息，你会发现它和Issuer里面的内容是一样的)
(6).Subject’s Public Key Info(证书所有人公钥，刚才所说的公钥就是这个!)
(7).Extension(扩展信息)
(8).Certificate Signature Algorithm(公钥加密算法)
以上这几项就是上面所说的证书内容(F)。
2.Certificate Signature Algorithm:
这是描述证书的加密算法，就是上所说的加密算法(A)，看它的Fireld Value，一般会写：PKCS #1 SHA-1 With RSA Encryption
3.Certificate Signature Value:
这记录的是证书被加密后的结果，相当于上面说讲的F’。
疑问
CA证书生成的时候已经签名了，如果中途证书被篡改，那按理说不能正常解开签名，即便是篡改，我也可以按照证书里的摘要算法进行篡改，hash不是多此一举？
因为根据pkcs#11，非对称算法RSA只能加密比私钥小27Byte的数据，假设私钥是1024bits的，那么加密内容不能超过997Bytes，这根本不够看，于是一个长报文就要全裁成997bytes一段，加密发送。同时非对称加密又极度耗费系统资源，哪怕只是将一个图片分块加密解密，就够服务器喝一壶。所以一般都是将内容hash后对hash结果进行非对称加密签名，用于降低系统的开销，而消息本身使用对称加密进行保护，因为对称加密速度快资源小。
通过CA生成证书
查看安装信息
1 | openssl version -a # 查看openssl安装目录 |
初始化demoCA目录
1 | 如果目录不存在就创建 |
生成CA根证书
生成 CA 根密钥：
1 | cd CA |
自签发 CA 根证书：
1 | openssl req -new -x509 -key ./private/cakey.pem -out ./cacert.pem -days 7300 |
将 PEM 格式证书转为常用的 DER 格式：
1 | openssl x509 -inform PEM -in ./cacert.pem -outform DER -out ./CA.cer |
签发CA证书
生成RSA密钥
1 | mkdir infotech.vip |
生成证书请求
1 | openssl req -new -key ./infotech.vip/infotech.vip.key -out ./infotech.vip/infotech.vip.csr |
签发证书
1 | openssl ca -in ./infotech.vip/infotech.vip.csr -out ./infotech.vip/infotech.vip.crt -days 3650 # countryName stateOrProvicename需要一样，openssl.cnf中CA policy有三个match，必须要填一样的，或者改成optional |
查看证书
1 | openssl x509 -text -in infotech.vip.crt -noout |
问题
failed to update database TXT_DB error number 2 证书信息不能都一样
方法一：CA下 index.txt.attr文件将unique_subject = yes 改为unique_subject = no
方法二：将 common name设置成不同的