The principle https

Detailed https

Currently, most large sites have all been switched to the httpsservice, so it is necessary to understand the whole httpsprinciple, httpsis how to ensure information security. Here I hope you have some understanding of the term following sections:

• Digital certificates
  are Internet communications identity (mainly user identity information and public key), generally issued by the CA center, both CA Certification Center, or third-party authority. Digital certificates typically include: CA's signature, public key certificates of all, the center of the CA signature algorithm, fingerprint and fingerprint algorithm, certificate's unique number, version, expiry date.
• Digital signature, signature algorithm
  summary of the information through the [ hash算法/ 摘要算法/ 指纹算法information calculation 摘要/ hash值] signature algorithm used for encryption, the ciphertext obtained is called a digital signature
• Fingerprint, fingerprint algorithm / hash value calculation digest algorithm []
  of the message using hash算法/摘要算法a one-way process, acquires information of a fixed length 摘要/hash值.
• Asymmetric encryption
  using public key, private key corresponding to the decomposition encryption, decryption algorithm, i.e., use different encryption and decryption keys bunch.
• Symmetric encryption
  uses the same secret key for encryption and decryption algorithms
• Public, private
  asymmetric one pair of encryption and decryption keys.

https service deployment process and principles

Understand httpsthe principle, the best way is to take over the process, in theory, process and principles explained by the following:

1. Certificate Request
2. Certificate Trust
3. Mitsubun communication

Obtain a certificate of

httpsOne of the keys is the sslcertificate, the certificate in order to ensure the safety and effectiveness of cooperation between the various types of committees / vendors to form a number of authoritative certification body through a similar round table [top certification bodies may have certain subsidiaries of secondary and tertiary ... CB], you want to get a trusted certificate, you need to submit a certificate signing request (CSR, certificate signing request) to the CA organization. Process is as follows:

1. [General certificate applicant is a company, such as individual developers] need to use encryption algorithm [most of] the RSA algorithm to generate a private key, private key is stored on the server which is not available to anyone.
2. Using the private key to generate a certificate signing request (CSR, Certificate Signing Request) [CSR] is included with the public key, applicants need to provide some information related to the domain name [,] the owner and other information sent to the CA organization asked for their signature, after they signed to become a trusted certificate.
3. CA agency for the applicant to verify different types of charging different [here,] authentication methods will be different, after verification by, some of the information will be added in the certificate [certificate authority, expiry date, fingerprint / hash algorithm, signature algorithm] form the new certificate. [CA organization also uses its own private key to sign other Certificates]

4. The new certificate is signed, follow these steps:

   • The new certificate in accordance with the 指纹/hash算法calculation hash value
   • Using the CA private key calculated hash value is encrypted in accordance with the signature algorithm, ciphertext is obtained a digital signature;
   • The digital signature on the certificate of completion of the final surface [signature] to obtain a full certificate, and those who returned to the applicant;
   • Applicants get signed certificates to ensure that their HTTPSservice be trusted.

So last certificate in the basic content including but not limited to the following:

• The certificate is valid
• Public Key
• Certificate owner (Subject)
• Signature algorithm used
• Fingerprint algorithm and fingerprint algorithm [hash]
• Version Number, version number.
• Serial Number, Serial Number.
• Authorities
• digital signature

Client identification certificate

After application to a trusted certificate, the client is aware of how these certificates are trusted it, realization of different browsers and systems are not the same, but about the same basic way, are prepared in a system or browser good information about the authority of the CA organization [public key, often used all kinds of hash, signature, encryption algorithms, etc.]. Specific process is as follows:

1. Browser to access a httpsservice, put the browser itself supported by a series of Cipher Suite (key algorithm suite, hereinafter referred to as Cipher) [C1, C2, C3 , ...] [to the server algorithm suite includes 非对称算法、对称算法、hash算法];
2. After all Cipher server receives the browser with its own support package for comparison, if supported by both sides [find Cipher Suite algorithm can support the highest priority], then tells the browser and return to their own certificate;
3. Browser and server acknowledgment subsequent ciphertext communication encryption algorithm, and the certificate authentication;
4. Use of the certificate may be [in secondary and tertiary institutions] [public key systems, browsers] prepared in advance in accordance with the certificate to decrypt the signature algorithm [certification authority using a private key encryption ciphertext only through the certificate authority public key to decrypt], decryption Huoqu hash value;
5. Certificate using hash/摘要算法the certificate information of the certificate, but excluding the signature information [server's public key, validity period, etc.]] calculated hash value and the decrypted hash value 4 are compared, if they are equal, it indicates that the certificate be trusted; [guaranteed by digital signature contents of the certificate has not been tampered].

https encrypted communication procedure

After the above process [certificate trust, client and server handshake required 非对称算法, 握手信息验证的hash算法, 正文传输的对称加密] it is a specific communication process:

1. The client trust the certificate of the server, and the server, and the two sides confirmed the encryption algorithm [handshake required 非对称算法, 握手信息验证的hash算法, 正文传输的对称加密];
2. 客户端生成随机数，通过证书中的公钥按照约定的非对称加密算法进行加密，得到加密的随机数秘钥，同时将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥和加密签名发送到服务端。
3. 服务端收到随机数秘钥和加密签名，先使用私钥将随机数按照约定的非对称解密算法进行解密，获取随机数，同时使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否。
4. 成功以后，服务器再次将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥发送到客户端，
5. 客户端使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否，
6. 成功的话整个链接过程完成，之后将使用随机数和约定的对称加密算法进行密文通信，【如果上面的任何步骤出现问题，都将会结束整个握手过程，导致建立安全连接失败】。

整个过程其实还有很多细节；ssl握手报文

综合解惑

这里的整个过程分的很细，不过还是很清晰的把整个https的原理和过程阐述了;下面解释一下其中一些疑惑点：

1. CA机构认证的作用？
   可以作为全球有限的权威认证，经过其签名的证书都可以视为可信任的，所以他们的私钥必须要保证不被泄露，如果泄露的话需要及时的进行吊销，
2. 签名为什么需要加密计算的hash值，hash值已经是单向不可逆的运算了？
   因为虽然hash值是单向的，但是计算hash的算法和内容都是公开的，如果不进行加密，那么由于其他人可以修改证书内容，根据hash算法重新计算hash，这样就会出现安全漏洞，所以使用加密的密文才是安全的。
3. 为什么要有随机数，为什么在客户端生成？
   随机数是作为后续整个密文加解密的关键秘钥，只有获取这个随机数的人才可以看到通信的内容，保证通信的安全；通过客户端产生是因为会话的发起者是用户端，为了保证用户端的唯一，以及保证服务端和客服端的会话内容不被篡改，如果是服务端来生成的话，第三方可以通过公钥来解密服务端加密的随机数，存在不安全因素。
4. 证书验证完成后，为什么客户端需要和服务端互相发送一次签名信息？
   证书验证完成以后，需要传递一个随机数，使用公钥、私钥进行非对称加解密，后面在发生内容消息的前面是为了验证通过随机数进行对称加解密，保证双方获取的数据正确性。

openssl生成证书

在大部分开发调试过程中，我们需要本地调试https的页面时候，我们需要在本地拥有证书，而openssl就是就是这样一个集成工具；通过使用openssl来完成本地调试https的请求。

1. openssl简介
2. 自签名证书
3. 本地私有CA证书

openssl的简介

OpenSSL 是一个开源项目，其组成主要包括一下三个组件：

1. openssl：多用途的命令行工具
2. libcrypto：加密算法库
3. libssl：加密模块应用库，实现了ssl及tls

openssl可以实现：秘钥证书管理、对称加密和非对称加密更多简介和官网和openssl简介。

自签名证书

为了能够把线上的https的请求，走向本地，需要我们本地也有https服务，那么证书就是不可避免的，然而一般情况我们并不是使用线上的证书，因为走本地需要本地启用服务，如果证书使用线上的，那么本地起服务的话就需要线上的私钥等隐私信息，这很容易导致私钥泄露，所以不安全，那么我们就需要生成一个本地的证书；

前文讲过了，一个证书是需要经过CA机构进行认证签名的，那么我们本地测试使用的证书然道也要去申请认证吗？但是否定的，因为这个这是只是我们本地使用，所以只需要我们有证书，并且手动添加信任就行，那么自签名证书就很好的解决了这个问题。

自签名证书：跟多详细介绍，自签名证书的核心就是自己对自己的申请进行签名【CA根证书就是这样产生的】；使用自己的私钥对自身生成的证书申请CSR进行签名得出的证书。

通过自签名证书我们获得了https服务需要的证书，根据本地不同的环境，都需要对该证书进行一个信任，这样我们本地起的https服务才会被浏览器正确的识别。整个过程如下：

1. 生成秘钥

   openssl genrsa -des3 -out cwj.key 2048

   使用以上命令，来生成一个我们本地需要的私钥，后面需要使用私钥来生成证书申请CSR以及对证书申请CSR使用私钥进行自签名

2. 生成证书申请CSR

   openssl req -new -key cwj.key -out cwj.csr

   需要填写一系列信息，包括地点、单位、域名、email之类的，这里会自动使生产与服务端私钥匹配的公钥，CSR中包含了公钥；

3. 使用私钥完成自签名，生成完整的证书

   openssl x509 -req -sha256 -days 3650 -in cwj.csr -signkey cwj.key -out cwj.crt

   使用前生产的秘钥对证书申请CSR进行信任签名，得到完整的证书；

这样的确满足了部分需求，只需要使用该证书和私钥来启动https服务，同时本地信任这个证书就大功告成了，其中优点如下：

1. 本地自签名，无须CA根证书；
2. 过程简单

不过也存在一些弊端：

1. 该证书无法被吊销，私钥需要保存好，不过对于仅用于本地调试来说就无伤大雅；
2. 多域名需要多个证书，需要根据域名生成多个证书，客服端需要分别信任这些证书。【不过openssl也可以生成多域名证书，一个证书可以供多个域名使用，一般使用openssl.cnf配置文件来生成】

所以还存在其他的方法：为了模拟完整的真是的https服务，我们可以在本地生成一个类似CA根证书，通过CA的私钥来对其他的所有的本地证书进行签名，只有信任了本地的CA根证书，那么他签名的证书都会被信任，这样就是下面文提到的进化方法本地私有CA根证书。

本地私有CA根证书伪CA根证书

这个方法的整体流程就是本地生成一个CA证书，就类似CA机构的存在，【暂且称为伪CA根证书】通过伪CA根证书的私钥来对其他的所有的本地证书进行签名，我们本地信任了这个伪CA根证书，那么通过伪CA根证书签名的证书都会被信任。避免了多个域名需要生成多个自签名证书以及要进行分别信任的复杂行为。

1. 伪CA根证书生成并添加信任

   openssl genrsa -des3 -out ca.key 2048
   openssl req -new -key ca.key -out ca.csr
   openssl x509 -req -sha256 -days 3650 -in ca.csr -signkey ca.key -out ca.crt

   可以看到，其实ca根证书就是一个自签名证书的例子；

2. 本地单一域名证书秘钥、申请CSR

   openssl genrsa -des3 -out cwj.key 2048
   openssl req -new -key cwj.key -out cwj.csr

   生成一个证书请求；

3. 伪CA根证书的私钥签名其他的申请CSR

   openssl x509 -req -sha256 -days 3650 -in cwj.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out cwj.crt

更多内容openssl;这样证书的问题就解决了，视情况来看使用者是采用哪种方案来生成证书。

信任证书需要一些操作，不同系统有不同的过程，MAC是在钥匙串中信任，windows是需要导入证书；

nginx部署https实践

Local Startup httpsmany ways to serve, we talk about here nginx; nginx official website https module , the main use is the private key and certificate; a certificate private key is generated using different methods previously mentioned as well as the local server [CA root certificate is also required locally trust].

server {
        listen       443 ssl;
        server_name  cwj.cc;

        ssl_certificate /cwjhttps/cwj.crt; ssl_certificate_key /cwjhttps/cwj.key; ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { root /cwjhttps; index home.html index.htm test.html; } } 

In fact, such an approach in chromethe high version will still be considered unsafe website; behind the opensslbriefing explaining specific, or see a self-signed certificate process detailed and resolve chrome does not trust self-signed certificate , digest / hash algorithm is not considered safe