HTTPS

HTTPS协议其实就是http和tcp/ip协议之间加了一层TLS协议，用来保证http数据的机密性和完整性。

CA证书

CA证书保证了服务器确实是服务器。
访问带有CA证书的服务器最常见的就是浏览器地址栏带有一把小锁，例如Edge浏览器

PKI

全称Public Key infrastructure（公钥基础设施），在网络通信中，TLS协商协议虽然可以解决数据加密和完整性的问题，但是 通信双方往往无法验证通信对方的身份，可能会遭到中间人攻击。PKI技术被用来解决 身份验证的问题。

PKI技术能够确保客户端接收到的服务器公钥（比如 www.abc.com网站的公钥）确实是 www.abc.com网站的公钥。

服务器实体：服务器实体就是HTTPS网站的提供者。
客户端：一般是浏览器。
CA机构：CA机构会向服务器实体签发一张证书，CA机构都是可以被信任的第三方组织，如果CA机构没有充分核验申请者的信息，签发了一个伪造证书，那么它将失去自己的威信。

CA机构拥有一个密钥对，它用私钥对证书进行 数字签名，将签名的证书发送给服务器。浏览器连接服务器时，服务器发送证书给浏览器，浏览器拥有CA机构的公钥（内嵌在操作系统中），然后校验证书的签名，一旦校验成功，就代表这个证书是可信的CA机构签发的。
成功验证签名只能表示该证书是CA机构签发的，然后浏览器会继续校验，比如用户访问的网址是 https://www.abc.com，如果发现证书包含的域名也是 www.abc.com，则代表校验身份成功，最后浏览器从证书中获取服务器的公钥，用来进行密钥协商。

X.509标准

X.509标准是PKI的标准，HTTPS的证书都使用X.509标准，最通用的是X.509 V3版本，引入了扩展的概念。 证书是PKI的核心，扩展是证书的核心，校验证书必须严格处理证书扩展。
在X.509标准下，PKI组成如下：
其中 OCSP是在线证书状态协议，用来验证SSL证书的有效性，检查是否被吊销。
证书库里存储了该CA机构签发的所有证书。

X.509标准包含了许多内容，其中有：
1.证书的作用，CA机构为服务器实体担保。
2.证书的文件结构
3.管理证书，例如服务器实体申请证书的流程，CA签发证书的流程。
4.校验证书，一个是证书签名，一个是服务器实体的属性，例如域名。
5.证书撤销问题，例如证书吊销列表CRL和OCSP在线证书状态协议服务。

证书结构

ASN.1

ASN.1是国际电信联盟电信标准（ITU-T）定义的一个标准，用来结构化描述证书，类似于xml schema或dtd的作用。
可以在浏览器https网站小锁处查看证书，ASN.1证书的数据结构如下：

//SEQUENCE是ASN.1的一个结构体，相当于一个多维数组，可以嵌套。
//它的内容被称为一个个的元素，元素有名称（左）和属性（右）
Certificate  ::=  SEQUENCE  {  
    tbsCertificate      TBSCertificate,//核心内容，包括服务器实体和CA的信息
    signatureAlgorithm   AlgorithmIdentifier,//CA的签名算法，对tbsCertificate签名
    signature          BIT STRING //签名值
}

TBSCertificate  ::=  SEQUENCE  {
    version        [0]  Version DEFAULT v1,//证书版本号，目前有v1，v2，v3
    serialNumber        CertificateSerialNumber,//序列号，证书的唯一编号，int型
    signature          AlgorithmIdentifier,//包含摘要和签名算法，例如RSAWithSHA256
    issuer             Name,//CA机构的名称，主要由国家（C）、组织（O）、子组织名（CN）组成
    validity           Validity,//证书有效期
    subject            Name,//服务器实体名称，CN表示服务器实体的域名
    subjectPublicKeyInfo SubjectPublicKeyInfo,//服务器实体公开密钥算法和公钥
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,//可选，>=v2版本可使用，CA机构唯一编号，目前被证书扩展替代
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,//可选，>=v2版本可使用，服务器实体唯一编号，目前被证书扩展替代
    extensions     [3]  Extensions OPTIONAL  //可选，>=v3版本可使用，可以动态的增加证书新属性，是否生效取决于证书校验方
}

Version  ::=  INTEGER { v1(0), v2(1), v3(2) }

AlgorithmIdentifier ::= SEQUENCE {
    algorithm       OBJECT IDENTIFIER,
    parameters      ANY DEFINED BY algorithm OPTIONAL//额外的参数，可选
}
//证书有效期在notBefore和notAfter之间
Validity ::= SEQUENCE {
    notBefore     Time,
    notAfter      Time
}

SubjectPublicKeyInfo  ::=  SEQUENCE  {
    algorithm          AlgorithmIdentifier, 
    subjectPublicKey    BIT STRING //公钥的值
}
//公钥的值例如rsa，dh结构如下
RSAPublicKey ::= SEQUENCE {
    modulus     INTEGER, //模数n
    publicExponent   INTEGER //公开指数e
}
DHPublicKey ::= INTEGER //y = g^x mod p

//Extensions由多个Extension构成
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
    extnID   OBJECT IDENTIFIER,//扩展的OID对象
    /*critical表示扩展是否关键，如果为true，那么证书校验方必须根据该扩展的定义处理，如果证书校验方不知
    道该扩展的含义，无法处理，则证书校验失败；如果为false，则校验方可以忽略.
    X.509 V3定义了14个扩展
    */
    critical  BOOLEAN DEFAULT FALSE, 
    extnValue  OCTET STRING  //取决于extnID
}

证书扩展

分为标准扩展和私有扩展两种，私有扩展是证书签发者自行设计，一般用于服务器和客户端定制化校验。
X.509 V3标准扩展如下（部分）：
使用者可选名称（Subject Directory Attributes, SAN（ Subject Alternative Name）扩展）
CA密钥标识符（Authority Key Identifier）
使用者密钥标识符（Subject Key Identifier）
基础约束（basic constraints）
密钥用法（Key Usage）
密钥扩展用法（Extended Key Usage）
CRL分发点（CRL Distribution Points）
CA机构信息（Authority Information Access）

证书分类

根据CA机构对申请者身份审核的宽松程度，可以分为三类证书：DV证书、OV证书和EV证书。
DV证书审核时间快，但审核不够严谨，一般适用于个人小网站。
OV证书审核严格，审核时间较长，一般用于企业和政府机构。
EV证书审核最严格，审核时间最长，CA机构会严格根据CA/Browser论坛制定的标准审核申请者的身份，该标准称为Baseline Requirement标准，规定了身份审核的流程，适用于银行、电商、政府机构。

根据证书主机数量可以分为：单域名证书，泛域名证书、SAN证书、SAN泛域名证书。
单域名证书只包含一个域名。
注册域：在域名注册商购买的域名，比如 www.abc.com,则其泛域名为*. abc.com，不能是多级，例如 xx.yy.abc.com。
泛域名证书就是 将多个同级的主机例如 oa.abc.com和 erp.abc.com合并到一个证书里。
SAN证书可以将多个注册域合并到一个证书中，例如 www.abc.com和 www.abc.cn。
SAN泛域名证书，是SAN证书和泛域名证书的合体，可以将多个同级域名主机和多个注册域合并到一个证书，适用于有多个域名的大企业。

证书链

可以在浏览器小锁图标或者F12开发者工具Security页面查看证书链，百度的证书链如下

该证书链有三张证书，上一层签发下一层的证书，从下到上分别称为服务器实体证书、中间证书、根证书，其中中间证书可以有多层，根证书是自签名证书。

信任原理

根证书、中间证书与服务器实体证书关系如下：
除了根证书，每个证书的签发者是其上级名称。
除了根证书，每个下级证书被它的上一级证书签名，签名值包含在下级证书中，上级证书包含的公钥可以用来验证下级证书中的签名值。
根证书是证书链的最顶端，它的签名值是自己签名的，验证签名的公钥就包含在根证书中，根证书的签发者就是它自己。
根证书是一个信任锚（Trust anchor）

证书链校验

先获取证书链。当浏览器访问 https://www.abc.com时，服务器发送完整的证书链（不含根证书）给浏览器，浏览器根据服务器实体证书寻找完整证书链，浏览器从服务器实体证书中获取 CA密钥标识符（Authority Key Identifier），进而获取上一级中间证书文件，然后通过中间证书中的CA密钥标识符 不断迭代直到获取根证书。

浏览器不能充分信任服务器发送的证书链文件，需要 确保每个证书（除了根证书）的签发者（issuer）是它的上一级证书（证书链的上部）的使用者（subject），如果不符合该条件，证书校验失败。

迭代签名校验：
1.浏览器从服务器实体证书的上一级证书B获取公钥，用来校验服务器实体证书的签名，校验成功则继续，否则证书校验失败。
2.浏览器从B证书的上一级证书C获取公钥，用来校验B证书的签名，校验成功则继续，否则证书校验失败。
2过程不断迭代，直到发现某张证书的签发者和使用者是同一个值，说明找到了根证书，根证书使用自己的公钥验证签名，如果校验成功就代表完整的证书链校验成功。

信任锚

各个CA的根证书已集成在操作系统中，浏览器可以充分信任 根证书的签名，这就是信任锚。
在迭代校验过程中，必须有一个终点，如果没有 信任锚，那么下级证书永远需要一个上级证书来校验，校验将无限递归下去。

操作系统的根证书路径

各版本的操作系统存储根证书的路径各不相同

#在Linux环境下执行此命令
openssl version -a
#Debian/Ubuntu 根证书位置在 /usr/lib/ssl
#RedHat/CentOS 根证书位置在 /etc/pki/tls

windows系统可以 win+R键打开运行，输入certlm.msc打开证书管理界面

CA认证方式

委派认证

一般情况下，根CA机构不会直接签发服务器实体证书，因为各地域政策，文化不同，再加上世界各地有不计其数的组织要申请证书，工作量非常大，若都集中在几家CA机构上，那么证书审核流程会走的非常慢，所以它们一般都会委派给一些二级CA机构

交叉认证

一个新的CA机构X如果要投入服务，不可能立刻嵌入到客户端的可信任证书列表，解决的方案就是让另外一个已存在的根CA机构Y对其进行交叉认证，Y机构的根证书可以给X签发一张二级CA证书，该二级CA证书再签发服务器实体证书，由于大部分证书校验方集成了Y机构的根证书，所有由X机构签发的服务器实体证书就能够立即生效。

证书吊销

由于证书可以被吊销（但未过期），未过期的证书不能确保证书拥有者的身份，对于证书校验方来说，仅仅校验服务器实体证书并不能确定服务器实体的身份，需要通过一种机制校验证书的吊销状态，如果证书处于吊销状态，表明服务器实体身份校验失败。在PKI中，有两种机制能够完成该工作，分别是CRL和OCSP。
证书吊销有两种状态，分别是：
永久吊销，表示某张证书永久性地被吊销。
临时吊销，表示某张证书只是临时被吊销。
吊销的原因有以下几种：
1.某个CA机构错误签发了一张证书，为了让证书校验方取消信任该证书，CA机构可以吊销该证书，然后重新签发一张证书。
2.攻击者诱使CA签发了一张证书，CA机构发现后，有义务立刻吊销该证书。
3.服务器实体发现证书对应的密钥对（私钥）被泄露了，服务器实体立刻告知CA机构，期望快速吊销该证书，然后再签发一张证书。（常见原因）

CRL（已逐渐被OCSP取代）

全称Certificate Revocation List（证书吊销列表），通过CRL，证书拥有者才能合法地证明自己的身份， 仅仅凭借服务器实体证书并不能完整地确认服务器实体的身份。CRL标准是TLS/SSL协议的一部分。
CRL是一个文件，和证书一样，也使用ASN.1结构来解释其含义，每个CA机构将所有的吊销证书（由其签发的）集成在一个文件中，称为CRLs（Certificate Revocation Lists）。
CRLs相当于一个黑名单，包含了所有被吊销服务器实体证书的序列号和吊销原因，如果一个待校验服务器实体证书的序列号能够匹配CRLs，表示该证书被吊销了。

CRLs由CA机构发布，该文件在互联网上有一个URL地址，该地址称为 CRL分发点，CRL分发点以HTTP的形式提供。 证书中包含CRL分发点扩展。为了避免CRLs被篡改，CA会对CRLs进行数字签名，CRLs中包含了签名算法和签名值。需要注意的是，CA机构签发服务器实体证书的私钥和签发CRLs的私钥可以是不同的，甚至CA机构可以委托另外一家CA机构签发CRLs。

CA机构一般会用一个独立的证书对CRLs进行签名，如果某张证书如果要签发CRLs，该证书的 密钥用法（Key Usage）扩展必须被置为keyCertSign和cRLSign。证书校验方必须先校验CRLs文件的签名，从CRLs文件迭代找出证书链，完整的进行校验证书链的过程，验证CRLs的合法性。有时为了性能客户端也可以不校验签名，直接查询CRLs名单中是否包含待校验服务器证书的序列号，从而完成CRL校验。

结构

CertificateList  ::=  SEQUENCE  {
    tbsCertList         TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue      BIT STRING
}

TBSCertList  ::=  SEQUENCE  {
    // 版本号，必须是V2 版本
    version               Version OPTIONAL,
    // 签名算法，和CertificateList结构中的signatureAlgorithm一样。
    signature             AlgorithmIdentifier,
    // CRLs签发者
    issuer                Name,
    // CRLs本次更新时间
    thisUpdate            Time,
    // CRLs下次更新时间
    nextUpdate            Time OPTIONAL,

    // 被吊销的证书列表
    revokedCertificates    SEQUENCE OF SEQUENCE  {
        // 服务器实体证书序列号
        userCertificate        CertificateSerialNumber,
        // 服务器实体证书吊销时间
        revocationDate         Time,
        // 可选的扩展
        crlEntryExtensions     Extensions OPTIONAL
    }  OPTIONAL,

    // 可选的扩展
    crlExtensions          [0]  EXPLICIT Extensions OPTIONAL
}

校验过程

1.浏览器接收到服务器实体证书后，校验服务器实体证书的证书链是否可信，如果校验成功，则校验吊销状态。
2,。浏览器从服务器实体证书中找出CRL分发点。将整个CRLs下载到浏览器上，由于CRLs非常大，网络下载需要更多的时间，为避免频繁下载，浏览器会定期缓存CRLs结果，减少对CRLs的请求。
3.CRLs经过数字签名保护，客户端需要找到公钥验证签名，在CRLs文件中寻找CRLs的签发者，进而找到CRLs的完整证书链（包含集成到操作系统中的根证书），最终完成签名验证。
4.浏览器根据X.509 V2标准解析CRLs文件（随时间增大），得到ASN.1结构，该步骤非常消耗浏览器的CPU资源。
5.解析出ASN.1结构，如果待校验证书的序列号存在于CRL黑名单中，表示该证书被吊销了。

OCSP

由于CRLs黑名单随着时间会越来越大，变得难以维护，下载整个文件也越来越慢，并且其不是实时更新，所以CRL逐步被OCSP取代。
全称Online Certificate Status Protocol（在线证书状态协议），是PKIX工作组创建的一个新标准，不属于TLS/SSL协议，主要目的是替代CRL。
优点：
为了查询某张证书的吊销状态，客户端向OCSP提供方发送一个查询请求，OCSP提供方根据查询条件，直接返回该证书的吊销状态，并且证书的吊销操作会快速同步至OCSP服务器。

OCSP的结构也用ASN.1描述。OCSP服务由应用层协议提供，比如HTTP、SMTP、LDAP能够提供OCSP服务。在HTTPS网站中，一般使用HTTP提供OCSP响应服务。

请求结构

请求结构如下：

/*
请求结构主要包含四部分
1.OSCPRequest
2.Signature
3.TBSRequest
4.Request
*/
OCSPRequest    ::=    SEQUENCE {
    //请求的主要结构
    tbsRequest                TBSRequest,
    //可选，签名信息
    optionalSignature   [0]    EXPLICIT Signature OPTIONAL
}

Signature      ::=    SEQUENCE {
    //签名的算法
    signatureAlgorithm     AlgorithmIdentifier,
    //签名值
    signature             BIT STRING,
    //签名的完整证书链
    certs             [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

TBSRequest     ::=    SEQUENCE {
    //协议版本号
    version           [0]    EXPLICIT Version DEFAULT v1,
    //可选，表示OCSP请求者的名称
    requestorName      [1]    EXPLICIT GeneralName OPTIONAL,
    //表示OCSP请求的详细结构体，类似Request类型的数组
    requestList               SEQUENCE OF Request,
    //可选，表示OCSP的扩展，例如Nonce扩展，防止重放攻击，但是一般服务器不采用这个扩展，因为需要维护一个数据库
    requestExtensions   [2]    EXPLICIT Extensions OPTIONAL
}

Request ::=  SEQUENCE {
    reqCert                  CertID,
    //扩展
    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL
}

CertID  ::=  SEQUENCE {
    //哈希算法
    hashAlgorithm      AlgorithmIdentifier,
    //表示OCSP请求方对服务器实体证书的使用者名称(DN)进行摘要计算。
    issuerNameHash     OCTET STRING,
    //表示OCSP请求方对服务器实体证书的公钥进行摘要计算
    issuerKeyHash      OCTET STRING,
    //表示待校验证书的序列号
    serialNumber       CertificateSerialNumber
}

响应结构

响应结构如下：

/*
响应结构包含三部分
1.OCSPResponse
2.ResponseBytes
3.ResponseData
*/
OCSPResponse ::= SEQUENCE {
    //状态，如果失败则responseBytes为空，成功则返回详细信息
    responseStatus        OCSPResponseStatus,
    //响应体
    responseBytes         [0] EXPLICIT ResponseBytes OPTIONAL
}
//请求状态，ENUMERATED 类似枚举
OCSPResponseStatus ::= ENUMERATED {
    successful          (0),   //成功
    malformedRequest     (1),  //表示OCSP请求语法错误
    internalError        (2),  //表示OCSP服务遇到内部的错误，如果返回该错误，OCSP请求方应该进行重试
    tryLater            (3),   //表示服务临时不可用，稍后再尝试
    sigRequired          (5),  //表示OCSP请求方必须对请求进行签名，避免请求被攻击者篡改，OCSP请求方需要提供可选的证书供验证，如果OCSP提供方不能正确验证签名，则返回该错
    unauthorized         (6)   //表示请求未经授权
}

ResponseBytes ::= SEQUENCE {
    //响应类型，分别是id-pkix-ocsp和id-pkix-ocsp-basic
    responseType   OBJECT IDENTIFIER,
    /*
     取决于responseType，如果responseType的类型是id-pkix-ocsp-basic，则response
     对应的类型就是BasicOCSPResponse
    */
    response      OCTET STRING
}

BasicOCSPResponse ::= SEQUENCE {
    //OCSP响应的主要组成部分
    tbsResponseData     ResponseData,
    //签名算法
    signatureAlgorithm   AlgorithmIdentifier,
    //签名值
    signature          BIT STRING,
    //可选，表示签名的证书链，对OCSP响应进行签名
    certs          [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

ResponseData ::= SEQUENCE {
    //表示响应对应的协议版本
    version            [0] EXPLICIT Version DEFAULT v1,
    //表示响应的ID号
    responderID            ResponderID,
    //表示请求完成的时间
    producedAt             GeneralizedTime,
    //每个待校验服务器实体证书的状态信息,类似SingleResponse类型的数组
    responses              SEQUENCE OF SingleResponse,
    //可选，扩展
    responseExtensions   [1] EXPLICIT Extensions OPTIONAL 
}

SingleResponse ::= SEQUENCE {
    //表示证书的序列号，和OCSP请求的序列号一一对应
    certID                    CertID,
    //表示证书的状态
    certStatus                 CertStatus,
    //表示和该证书OCSP响应有关的时间，在thisUpdate和nextUpdate时间内，证书吊销状态是最新的
    //OCSP请求的时间应该处于{thisUpdate,nextUpdate}区间，避免获取的证书状态不是最新的。
    thisUpdate                 GeneralizedTime,
    nextUpdate        [0]      EXPLICIT GeneralizedTime OPTIONAL,
    //可选，扩展
    singleExtensions   [1]      EXPLICIT Extensions OPTIONAL
}
//证书状态
CertStatus ::= CHOICE {
    //表示在某个时间段，该证书是有效的，没有被吊销
    good       [0]    IMPLICIT NULL,
    //表示证书被吊销，吊销可能是临时的也可能是永久的。
    revoked    [1]    IMPLICIT RevokedInfo,
    //表示OCSP提供方并不知道待查询证书的相关信息，比如OCSP服务并不知道待校验证书的签署者是谁，无法进行响应
    unknown    [2]    IMPLICIT UnknownInfo
}

OCSP封套

实际部署HTTPS服务的时候，一般采用OCSP封套技术，OCSP封套技术的提出就是为了解决标准OCSP存在的一些问题（例如隐私性和重放攻击等）。

OCSP封套相比标准OCSP来说，不是由浏览器发出OCSP请求，而是由证书部署者即服务器负责发出OCSP请求。为了实现该技术，TLS/SSL协议定义了status_request扩展，对于浏览器和服务器来说，必须根据扩展定义协同实施OCSP封套技术。
OCSP封套处理流程如下所示：

1.浏览器在握手阶段发送一个status_request扩展，期望由代理服务器发出OCSP请求，自己仅仅是接收服务器的OCSP响应。
2.代理服务器接收到status_request扩展后，向OCSP服务发出请求，获取响应后，向客户端发出一个CertificateStatus子消息，该消息中包含了OCSP响应。如果服务器不能正确处理OCSP响应，可以不发送CertificateStatus子消息。
3.代理服务器为避免向OCSP服务发出过多的请求，一般会缓存OCSP响应。
4.CertificateStatus子消息包含的内容就是OCSP服务的响应。
5.如果浏览器没有接收到CertificateStatus子消息，表示代理服务器不能正确处理OCSP请求，则浏览器自行发出OCSP请求，和标准的OCSP处理是一样的。
6.如果浏览器接收到CertificateStatus子消息，直接校验该消息，获取服务器实体证书的吊销状态。

需要注意的是Chrome浏览器目前不打算支持OCSP。

申请证书流程

过程如下：
1.服务器实体准备好相关资料，例如域名、公司、等信息。
2.服务器实体利用公开密钥算法生成一对密钥，例如一对RSA密钥。
3.服务器实体生成一个CSR（Cerificate Signing Request）文件，其中包括网站的域名（ www.abc.com）、RSA密钥对的公钥、公司信息等等，然后将CSR文件发送给CA机构申请证书。
4.CA机构收到CSR文件后，需要仔细核实申请者的身份。
5.一旦审核成功，CA机构用自己的私钥签名CSR文件的内容得到签名值，然后将签名值附在CSR文件后面得到证书文件，证书文件中除了包含申请者的信息，还包括CA机构的信息，比如包括CA机构采用的签名算法、CA机构的名称。
6.CA机构将证书文件发送给服务器实体。

CSR

CSR 包含了用于签发证书的公钥、用于辨识的名称信息（Distinguished Name）（例如域名）、真实性和完整性保护（例如数字签名），采用的标准是PKCS#10。
还需要提供一些组织机构信息：
国家或地区代码：您的组织机构依法注册所在的国家或地区的代码，以国际标准化组织（ISO）的两字母格式表示。
省或市或自治区：您的组织机构所在的省或市或自治区。
城市或地区：您的组织机构注册所在的城市或地区。
组织机构：您的企业依法注册所用的名称。
组织机构单位：此字段用于区分组织机构中的各部门。
通用名称：在 CSR 的通用名称字段中输入的名称必须是您要为其使用证书的网站的完全限定域名（FQDN），一般是域名。
邮箱：邮箱地址。

其ASN.1结构如下：

CertificationRequest ::= SEQUENCE {
    certificationRequestInfo   CertificationRequestInfo,//表示证书的请求信息
    signatureAlgorithm         AlgorithmIdentifier,//服务器实体签名算法，用服务器实体私钥对certificationRequestInfo签名
    signature                 BIT STRING //签名值
}

CertificationRequestInfo ::= SEQUENCE {
    version      INTEGER { v1(0) } (v1, ...),//表示PKCS#10的版本号
    subject      Name,//表示服务器主体名称（DN），CN表示服务器实体的域名
    subjectPKInfo SubjectPublicKeyInfo,//服务器实体的公钥
    attributes   [0] Attributes //可选，服务器的邮件地址相关信息等
}

生成过程

1.服务器主体生成一对密钥对，例如RSA密钥对。
2.生成CertificationRequestInfo结构体，主要包含域名、公钥等等。
3.使用私钥对CertificationRequestInfo进行数字签名得到签名值。
4.组合CertificationRequestInfo信息和签名信息得到CSR文件。

openssl生成csr文件

openssl req -nodes -sha256 -newkey rsa:2048 -keyout abc.key -out abc.csr
#输入后会进入交互模式，填写可选的几个参数，最终生成 abc.key和abc.csr两个文件

openssl生成自签名证书

#通过密钥对和csr文件生成证书，有效期为365天，文件名为abc.cert
openssl x509 -signkey abc.key -in abc.csr -req -days 365 -out abc.cert

向CA机构发送CSR文件

服务器自己生成CSR文件，然后提交给CA机构，保证私钥安全。

由CA机构统一生成证书和密钥对

这种方式很方便，但是存在安全问题，把自己的私钥泄露给了CA机构。

免费证书

可以从Let's Encrypt处申请免费证书，它是一个CA机构，定义了ACME协议，将管理证书的流程进行了标准化、自动化，不用人工管理。
可以使用基于ACME协议的Certbot客户端免费向Let's Encrypt申请证书。

客户端验证证书流程

1.浏览器向服务器端发送连接请求 https://www.abc.com。
2.服务器接收到请求后，将证书文件和公钥发送给浏览器。
3.浏览器接收到证书文件，知道了是某CA机构的证书和证书签名算法，由于操作系统内置了可信任的CA机构的根证书，所以浏览器拿到该CA机构的公钥，验证是证书是该CA机构签发的。
4.浏览器接着校验证书申请者的身份，从证书中取出服务器的公钥和主机名，假设证书包含的主机也是 www.abc.com，且连接阶段接收到的公钥就是证书中包含的公钥，则表示浏览器成功校验了服务器的身份，连接的服务器确实是 www.abc.com主机的拥有者。

证书的完整校验过程

1.证书链校验
2.服务器实体证书校验
3.中间证书校验
3.吊销状态校验，根据CRL和OCSP进行校验。

HTTPS安全补充标准

HSTS

全称是 Http Strict Transport Security，是为了弥补https的弱点而出现（例如浏览器对自签名证书的松散管理，可以继续访问）。HSTS本质上是一个http的头部，https网站可以返回HSTS头部，告诉浏览器请遵守该标准，浏览器收到这个头部应该按照HSTS与服务器配合工作。只要有一方不按照HSTS执行，那么这个头部将是无效的。

HSTS头部如下：
Strict-Transport-Security: max-age=9999; includeSubDomains; preload
其中：
max-age是服务器要求客户端，在9999秒内，需要执行HSTS标准，客户端每次访问会刷新这个时间。
includeSubDomains是服务器要求客户端 域名及子域名（例如*. abc.com）都执行HSTS。
preload指 浏览器预先存储了一个实施HSTS网站的列表，目前这个列表由Chrome维护。

使用HSTS的效果具体表现如下：
1.当访问一个自签名证书的服务器时，直接终止访问，不会提示用户是否信任该证书。
2.用户访问 http://www.abc.com，浏览器会直接转换为 https://www.abc.com。
3.用户访问 https://www.abc.com时，会将页面中 http://www.abc.com/**开头的请求全转为https。注意，如果 http://www.abc.com包含 http://www.def.com，但 www.def.com对应的服务器没有输出HSTS头，那么访问 http://www.def.com/**将不会被转换。

和服务器301重定向类似，只不过HSTS重定向是在发出请求之前由客户端重定向。
客户端第一次访问一个服务器时，客户端不知道服务器带不带HSTS头，此时不会重定向，解决办法是使用HSTS preloading机制，由客户端预先加载改网站的域名。

常见的做法是在Nginx服务器上配置，统一输出HSTS头部。注意，要想使用HSTS，必须先部署HTTPS证书，且网站必须有域名而不是IP访问。
目前各种最新版的浏览器都支持HSTS。

CSP

全称 Content Security Policy，用来控制网页中https和http的混合内容加载，它也是一个http头部，用来防止XSS攻击。CSP也需要服务器和客户端配合工作才能生效。

混合内容

如果https页面包含http子资源，就说此页面含有混合内容。

主动混合内容

作为整体与页面进行交互，并且几乎允许攻击者对页面进行任何操作。主动混合内容包括js脚本、css、iframe、flash资源等及其他代码

被动混合内容

指不与页面其余部分进行交互的内容。例如图片、视频和音频内容，以及无法与页面其余部分进行交互的其他资源。

CSP能详细控制混合内容的加载，其头部如下:
Content-Security-Policy: "default-src 'self';"
其中，可以配置多个指令，如default-src，img-src，script-src等等，多个指令用分号隔开。
每条指令也可以由多个值，例如default-src 'self' 'https'等，多个值用空格隔开。
default-src可以控制js，图片，css的加载。
default-src 'none'表示不允许加载任何内容，default-src 'self'表示允许加载与主页面协议、域名、端口相同的内容。

---

参考：《深入浅出HTTPS：从原理到实战》虞卫东