原則HTTPS

httpsの詳細

現在、ほとんどの大規模なサイトはすべてに切り替えてきたhttps、全体の理解する必要があるので、サービスhttpsの原則を、https情報セキュリティを確保する方法です。ここで私はあなたの用語次のセクションのいくつかを理解している願っています：

• デジタル証明書は
  、一般的にCAの中心部、CA認証センター、またはサードパーティ認証機関の両方によって発行されたインターネット通信アイデンティティ（主にユーザーのID情報と公開鍵）、です。デジタル証明書は通常、含ま：CAの署名、すべての公開鍵証明書、CAの署名アルゴリズム、指紋と指紋アルゴリズムの中心部、証明書の固有の番号、バージョン、有効期限を。
• デジタル署名、署名アルゴリズム
  を介して情報の要約hash算法/ 摘要算法/ 指纹算法情報演算摘要/ hash值暗号化に使用される]の署名アルゴリズムは、得られた暗号文は、デジタル署名と呼ばれています
• 指紋、指紋アルゴリズム/ハッシュ値算出アルゴリズム[]ダイジェスト
  使用して、メッセージのをhash算法/摘要算法一方向のプロセスは、固定長の情報を取得します摘要/hash值。
• 非対称暗号
  公開鍵を使用して、分解の暗号化に対応する秘密鍵、復号アルゴリズム、すなわち、異なる暗号化と復号鍵の束を使用します。
• 対称暗号化は、
  暗号化と復号化アルゴリズムの同じ秘密鍵を使用しています
• 公共、民間の
  暗号化と復号鍵の非対称1ペア。

HTTPSサービスの展開プロセスと原則

理解https原理を、最良の方法は、プロセスを引き継ぐことで、理論的には、プロセスと原則は以下で説明しました：

1. 証明書要求
2. 証明書信頼
3. 密文通信

の証明書を取得

httpsキーの一つであるssl証明書、同様のラウンドテーブルを権威認証機関の数を形成するために委員会/ベンダーの様々なタイプ間の協力の安全性と有効性を確保するために、証明書[トップ認証機関は、第二級および第三級の一部の子会社を有していてもよいです... CB]、あなたが信頼できる証明書を取得したい、あなたがCA組織に証明書署名要求（CSR、証明書署名要求）を提出する必要があります。次のようにプロセスは以下のとおりです。

1. RSAアルゴリズム[のほとんど]は、秘密鍵を生成するために使用する暗号化アルゴリズムの必要性[一般証明書の申請者は、個々の開発者としての企業、である]、秘密鍵は誰にでも利用できないサーバー上に格納されています。
2. 証明書署名要求（CSR、証明書署名要求）を生成する秘密鍵を使用して、[CSR]公開鍵に含まれ、申請者がドメイン名に関連するいくつかの情報を提供する必要がある[、]所有者とCAの組織に送られた他の情報は後に、自分の署名を求めました彼らは、信頼できる証明書になるために署名しました。
3. 異なる充電の種類を確認する出願人のCA機関[ここで、】認証方法は、によって検証した後、情報の一部は、証明書に追加され、異なるであろう[認証機関、有効期限、指紋/ハッシュアルゴリズム、署名アルゴリズム]フォーム新しい証明書。[CA組織は、他の証明書に署名するために、自身の秘密鍵を使用しています]

4. 新しい証明書は、次の手順を実行し、署名されています：

   • 新しい証明書指纹/hash算法の計算ハッシュ値
   • 署名アルゴリズムに従って暗号化されているCA秘密鍵算出されたハッシュ値を使用して、暗号文は、デジタル署名を得ています。
   • 最終面[署名]の完了の証明書のデジタル署名は、完全な証明書を取得し、申請者に返却人に、
   • 応募者は、彼らのことを確認するために、署名証明書を取得するHTTPSサービスは信頼されます。

以下を含むがこれらに限定されない基本的なコンテンツの最後の証明書は、そう：

• 証明書が有効です
• 公開鍵
• 証明書の所有者（件名）
• 署名アルゴリズムを使用します
• 指紋アルゴリズムおよび指紋アルゴリズム[ハッシュ]
• バージョン番号、バージョン番号。
• シリアル番号、シリアル番号。
• 当局
• デジタル署名

クライアントの識別証明書

信頼できる証明書を申請した後、クライアントはこれらの証明書がそれを信頼されているかを認識している、異なるブラウザやシステムの実現は同じではありませんが、同じ基本的な方法については、システムまたはブラウザに用意されていますCA組織の権限についての良い情報[公開鍵は、多くの場合、ハッシュ、署名、暗号化アルゴリズムなどのすべての種類を使用]を。次のように具体的なプロセスは、次のとおりです。

1. アクセスするブラウザhttpsサービス、それ自体が暗号スイート（以下、暗号と呼ばれる鍵アルゴリズムスイート）[C1、C2、C3の一連によってサポートされているブラウザを入れ 、...] [サーバアルゴリズムスイートが含まに非对称算法、对称算法、hash算法]。
2. すべての暗号サーバは、比較のために、独自のサポートパッケージでブラウザを受け取った後、両面でサポートされている場合は、ブラウザと、自分の証明書への復帰を告げる[最高の優先度をサポートできる暗号スイートアルゴリズムを見つけます]。
3. ブラウザとサーバーの承認以降の暗号文通信の暗号化アルゴリズム、および証明書認証。
4. 証明書の使用はのみを通じて、秘密鍵暗号の暗号文を使用して、[公開キーシステム、ブラウザ]署名アルゴリズムを解読するために、証明書に応じて予め用意し、[認証局[二次および高等教育機関に]かもしれ復号化されたハッシュ値を取得するために復号化]に認証局の公開鍵、。
5. 証明書を使用してhash/摘要算法、比較し、それらが等しい場合、それは証明書が信頼できることを示しているされている署名情報[サーバの公開鍵、有効期限、等]計算されたハッシュ値と復号化されたハッシュ値4証明書の証明書情報を、しかし除く; [デジタル署名によって保証証明書の内容]は改ざんされていません。

HTTPS暗号化された通信手順

上記のプロセスの後、[証明書の信頼は、クライアントとサーバーのハンドシェイクが必要非对称算法、握手信息验证的hash算法、正文传输的对称加密]は、特定の通信プロセスは、次のとおりです。

1. サーバーの証明書、およびサーバー、および2つの側面は、暗号化アルゴリズムを確認し、クライアントの信頼[ハンドシェイクが必要非对称算法、握手信息验证的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实践

ローカル起動https奉仕する多くの方法、私たちはおよそここで話しnginx、nginxの公式ウェブサイトをHTTPSモジュール、主な用途は、秘密鍵と証明書であり、証明書の秘密鍵は、以前にローカルサーバと同様に言及した別の方法を使用して生成され、[CAのルート証明書も必要ですローカル]信頼しています。

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; } } 

実際には、中にこのようなアプローチchromeの高いバージョンはまだ危険なサイトとみなされます。後ろopensslの特定を説明するブリーフィング、または参照の自己署名証明書のプロセスは、詳細なと決意クロムが信頼ない自己署名証明書を行い、ダイジェスト/ハッシュアルゴリズムは安全と見なされていません