28-HTTPS

以下将介绍 HTTPS 运维安全相关要点，并使用 Mermaid 绘制图表进行直观展示。

HTTPS 运维安全要点

证书管理
- 证书有效期：及时更新证书，避免证书过期导致网站无法正常访问。
- 证书类型：选择合适的证书类型，如单域名证书、多域名证书、通配符证书等。
- 证书存储安全：确保证书文件的存储安全，防止证书泄露。
加密算法选择
- 使用高强度的加密算法，如 TLS 1.3 及以上版本，避免使用不安全的旧算法。
密钥管理
- 密钥的生成、存储和传输要安全，定期更换密钥。
服务器配置
- 合理配置服务器的 SSL/TLS 参数，如协议版本、加密套件等。
- 开启 HTTP 严格传输安全（HSTS），强制客户端使用 HTTPS 连接。
漏洞扫描与修复
- 定期进行漏洞扫描，及时修复发现的安全漏洞，如 Heartbleed 漏洞、POODLE 漏洞等。

Mermaid 图解

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([客户端请求]):::startend --> B(HTTPS 服务器):::process
    B --> C{证书是否有效?}:::decision
    C -->|是| D(选择加密算法):::process
    C -->|否| E(提示证书过期):::process
    D --> F(建立安全连接):::process
    F --> G(数据传输):::process
    G --> H(服务器处理请求):::process
    H --> I(返回响应结果):::process
    I --> F
    F --> B
    B --> A

    subgraph 运维安全措施
        style 运维安全措施 fill:#ffffff,stroke:#000000,stroke-width:2px
        J(证书管理):::process
        K(加密算法选择):::process
        L(密钥管理):::process
        M(服务器配置):::process
        N(漏洞扫描与修复):::process
    end

    J --> C
    K --> D
    L --> F
    M --> B
    N --> B

代码解释

客户端请求：客户端向 HTTPS 服务器发起请求。
证书验证：服务器检查证书的有效性。如果证书有效，继续选择加密算法；如果证书过期，提示客户端证书过期。
加密算法选择：选择合适的加密算法来建立安全连接。
安全连接建立：使用选定的加密算法和密钥建立安全的连接。
数据传输：客户端和服务器之间通过安全连接传输数据。
服务器处理请求：服务器接收到请求后进行处理，并返回响应结果。
运维安全措施：
- 证书管理：确保证书的有效期和存储安全，影响证书验证环节。
- 加密算法选择：选择高强度的加密算法，影响加密算法的选择过程。
- 密钥管理：保证密钥的安全生成、存储和传输，影响安全连接的建立。
- 服务器配置：合理配置服务器的 SSL/TLS 参数，影响整个 HTTPS 服务器的运行。
- 漏洞扫描与修复：定期扫描和修复安全漏洞，确保服务器的安全性。

通过以上的运维安全措施，可以保障 HTTPS 服务的安全性和可靠性。

网络安全背景

网络就是实现不同主机之间的通讯。网络出现之初利用TCP/IP协议簇的相关协议概念，已经满足了互连两台主机之间可以进行通讯的目的，虽然看似简简单单几句话，就描述了网络概念与网络出现的目的，但是为了真正实现两台主机之间的稳定可靠通讯，其实是一件非常困难的事情了，如果还要再通讯的基础上保证数据传输的安全性，可想而知，绝对是难上加难，因此，网络发明之初，并没有太关注TCP/IP互联协议中的安全问题。

对于默认的两台主机而言，早期传输数据信息并没有通过加密方式传输数据，设备两端传输的数据本身实际是明文的，只要能截取到传输的数据包，就可以直接看到传输的数据信息，所以根本没有安全性可言。

早期利用明文方式传输的协议有：FTP、HTTP、SMTP、Telnet等。

后来就出现了加密的通讯方式，实际应用如 ssh、https

网络安全涉及问题

通过上文的介绍，其实已经了解到早期网络设备间进行通讯时，是采用明文进行数据传输的，并没有网络安全技术可言。

我们可以提出一种假设，如果在网络上的两台主机之间传输数据，就是采用明文的方式；并且对于网络传输而言，并没有相关的网络安全技术保驾护航，这样在互联网上进行数据传输，都有哪些网络风险需要进行面对。

数据机密性

网站数据机密性概述

网站数据机密性指的是确保网站所处理、存储和传输的数据仅被授权方访问和理解，防止数据在整个生命周期中被未授权的第三方获取。对于网站而言，涉及的机密数据可能包括用户的个人身份信息（如姓名、身份证号）、财务信息（如信用卡号、银行账户）、商业机密（如企业的战略规划、客户名单）等。一旦这些机密数据泄露，可能会给用户和企业带来严重的损失，如个人隐私泄露、财务损失、企业声誉受损等。

HTTPS对网站数据机密性的保障作用

1. 数据加密传输

原理：HTTPS 是在 HTTP 协议的基础上加入了 SSL/TLS 协议，通过加密算法对数据进行加密处理。在建立连接时，客户端和服务器会协商使用的加密算法和密钥。例如，常见的加密算法有 AES（高级加密标准），它可以将明文数据转换为密文，只有拥有正确密钥的接收方才能将密文还原为明文。
示例：当用户在浏览器中访问一个 HTTPS 网站并输入登录信息（用户名和密码）时，这些信息会被加密后再通过网络传输到服务器。即使数据在传输过程中被截取，攻击者由于没有解密密钥，也无法获取其中的敏感信息。

2. 身份验证

原理：HTTPS 使用数字证书来验证服务器和客户端的身份。服务器证书由受信任的证书颁发机构（CA）签发，包含了服务器的公钥和一些标识信息。客户端在与服务器建立连接时，会验证服务器证书的有效性。如果证书有效，客户端会使用服务器的公钥进行加密通信，确保数据是发送到合法的服务器。
示例：当用户访问一个银行网站时，浏览器会检查该网站的 SSL 证书。如果证书是由知名的 CA 颁发且未过期，浏览器会显示安全锁图标，提示用户可以安全地与该网站进行交互。这样可以防止用户误访问到钓鱼网站，从而保护用户的机密信息。

3. 防止中间人攻击

原理：中间人攻击是指攻击者在客户端和服务器之间拦截并篡改数据的攻击方式。HTTPS 通过加密和身份验证机制可以有效防止这种攻击。由于数据是加密传输的，攻击者无法轻易解密和篡改数据；同时，通过证书验证可以确保客户端和服务器之间的通信是直接的，没有中间人介入。
示例：假设攻击者试图在用户和电商网站之间进行中间人攻击，拦截用户的购物订单信息。但由于使用了 HTTPS，攻击者无法解密订单信息，也无法通过证书验证伪装成合法的服务器，从而无法实施攻击。

提升网站数据机密性的 HTTPS 相关实践

1. 正确部署和配置 HTTPS

选择合适的 SSL/TLS 版本，避免使用已被发现存在安全漏洞的旧版本，如 SSLv3 已被弃用。
配置强加密套件，如 AES-GCM 系列，确保数据加密的强度。
定期更新 SSL 证书，避免证书过期导致用户信任问题。

2. 实施 HTTP 严格传输安全（HSTS）

HSTS 是一种安全策略，通过在 HTTP 响应头中添加特定字段，告知浏览器在一定时间内只能通过 HTTPS 访问该网站。这样可以防止用户在访问网站时被重定向到不安全的 HTTP 版本，从而提高数据传输的安全性。

3. 监控和审计

定期监控网站的 HTTPS 连接情况，检查是否存在异常的连接请求或证书错误。
对网站的访问日志进行审计，及时发现潜在的安全威胁。例如，查看是否有异常的登录尝试或数据下载行为。

在网络传输数据信息时，对数据的加密是至关重要的，否则所有传输的数据都是可以随时被第三方看到，完全没有机密性可言。

数据机密性示意图

数据完整性

网络传输数据的完整性，也是安全领域中需要考虑的重要环节，如果不能保证传输数据的完整性，那传输过程中的数据就有可能被任何人所篡改，而传输数据双方又不能及早的进行发现。

将会造成互连通讯双方所表达信息的意义完全不一致。因此，对于不完整的数据信息，接收方应该进行相应判断，如果完整性验证错误，就拒绝接收相应的数据。

身份验证问题

网络中传输数据时，很有可能传输的双方是第一次建立连接，进行相互通讯，既然是第一次见面沟通，如何确认对方的身份信息，的确是我要进行通讯的对象呢？

如果不是正确的通讯对象，在经过通讯后，岂不是将所有数据信息发送给了一个陌生人。

这也是ssh要做的指纹确认的原因。

解决如上问题

网络安全涉及很多方面，而网络数据的安全传输通常会面临以下几方面的威胁：

数据窃听与机密性： 即怎样保证数据不会因为被截获或窃听而暴露。
数据篡改与完整性： 即怎样保证数据不会被恶意篡改。
身份冒充与身份验证： 即怎样保证数据交互双方的身份没有被冒充。

针对以上几个问题，可以用以下几种数据加密方式来解决（每种数据加密方式又有多种不同的算法实现）：

数据加密方式	描述	主要解决的问题	常用算法
对称加密	指数据加密和解密使用相同的密钥	数据的机密性	DES, AES
非对称加密	也叫公钥加密，指数据加密和解密使用不同的密钥--密钥对儿	身份验证	DSA，RSA
单向加密	指只能加密数据，而不能解密数据	数据的完整性	MD5，SHA系列算法

对称加密

1. 对称加密原理简介

在 HTTPS 中，对称加密用于在客户端和服务器建立安全连接后，对传输的数据进行加密。对称加密使用相同的密钥对数据进行加密和解密。在 HTTPS 流程里，客户端和服务器会先通过非对称加密等方式协商出一个对称加密密钥，后续就使用这个密钥来快速加密和解密大量的数据，以提高传输效率。

2. Mermaid 图解代码

sequenceDiagram
    participant C as 客户端
    participant S as 服务器
    Note over C,S: 1. 协商对称加密密钥
    C->>S: 发送客户端支持的加密算法等信息
    S->>C: 选择加密算法，返回服务器证书和协商的对称密钥信息
    C->>S: 验证证书，生成对称加密密钥
    S->>C: 双方使用相同的对称加密密钥
    Note over C,S: 2. 数据传输阶段使用对称加密
    C->>S: 使用对称密钥加密数据 <br/> （如用户登录信息）
    S->>C: 使用对称密钥解密数据
    S->>C: 处理请求后，使用对称密钥加密响应数据
    C->>S: 使用对称密钥解密响应数据

3. 代码解释

协商对称加密密钥阶段
- 客户端向服务器发送自己支持的加密算法等信息，告知服务器自己有哪些加密能力。
- 服务器从客户端支持的算法中选择一个合适的加密算法，同时返回自己的证书和一些用于协商对称密钥的信息。
- 客户端验证服务器证书的合法性，确保自己是在和合法的服务器通信。然后客户端根据协商信息生成对称加密密钥。
- 至此，客户端和服务器拥有了相同的对称加密密钥。
数据传输阶段
- 客户端在向服务器发送数据（例如用户登录信息）时，使用协商好的对称密钥对数据进行加密，然后将加密后的数据发送给服务器。
- 服务器接收到加密数据后，使用相同的对称密钥进行解密，获取原始数据。
- 服务器处理完客户端的请求后，将响应数据使用对称密钥加密，再发送给客户端。
- 客户端接收到加密的响应数据后，使用对称密钥进行解密，得到服务器的响应内容。

通过这种方式，在 HTTPS 通信中利用对称加密高效地保护了数据在传输过程中的机密性。

对称加密算法，如其名，就是使用同一个秘钥进行加密和解密。

优点是速度较快，适合对数据量比较大的数据进行加密。

缺点是密钥的保存方式需要保证，一旦加密或者解密的哪一方泄漏了密钥，都会导致信息的泄漏。

常用的对称加密算法有:DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6、AES。

非对称加密

非对称加密在 HTTPS 中的作用

在 HTTPS 协议里，非对称加密主要用于密钥交换和身份验证。服务器和客户端利用非对称加密算法（如 RSA）来安全地交换对称加密密钥，同时通过数字证书验证彼此的身份。非对称加密使用一对密钥，即公钥和私钥，公钥公开，私钥保密。加密时使用公钥，解密时使用对应的私钥。

Mermaid 图解

sequenceDiagram
    participant C as 客户端
    participant S as 服务器
    participant CA as 证书颁发机构

    Note over C,S: 1. 服务器获取数字证书
    S->>CA: 请求数字证书，携带公钥
    CA->>S: 验证信息后，颁发数字证书（含服务器公钥）

    Note over C,S: 2. 客户端发起连接请求
    C->>S: 发送客户端支持的 SSL/TLS 版本、加密算法列表等信息

    Note over C,S: 3. 服务器响应
    S->>C: 选择 SSL/TLS 版本和加密算法，发送数字证书

    Note over C,S: 4. 客户端验证证书
    C->>CA: 验证证书的有效性
    CA->>C: 返回验证结果
    alt 证书有效
        C->>C: 从证书中提取服务器公钥
    else 证书无效
        C->>C: 终止连接
    end

    Note over C,S: 5. 客户端生成会话密钥
    C->>C: 生成会话密钥
    C->>S: 使用服务器公钥加密会话密钥并发送

    Note over C,S: 6. 服务器解密会话密钥
    S->>S: 使用私钥解密得到会话密钥

    Note over C,S: 7. 双方使用会话密钥进行对称加密通信
    C->>S: 使用会话密钥加密数据并发送
    S->>S: 使用会话密钥解密数据
    S->>C: 使用会话密钥加密响应数据并发送
    C->>C: 使用会话密钥解密响应数据

流程解释

服务器获取数字证书：
- 服务器生成一对公钥和私钥，然后向证书颁发机构（CA）请求数字证书，将自己的公钥发送给 CA。
- CA 验证服务器的身份信息后，使用自己的私钥对服务器的公钥和相关信息进行签名，生成数字证书并颁发给服务器。
客户端发起连接请求：
- 客户端向服务器发送自己支持的 SSL/TLS 版本和加密算法列表等信息，表明自己的能力。
服务器响应：
- 服务器从客户端支持的信息中选择合适的 SSL/TLS 版本和加密算法，并将自己的数字证书发送给客户端。
客户端验证证书：
- 客户端接收到服务器的数字证书后，向 CA 验证证书的有效性。
- 如果证书有效，客户端从证书中提取服务器的公钥；如果证书无效，客户端终止连接。
客户端生成会话密钥：
- 客户端生成一个会话密钥，用于后续的对称加密通信。
- 客户端使用服务器的公钥对会话密钥进行加密，并发送给服务器。
服务器解密会话密钥：
- 服务器使用自己的私钥对加密的会话密钥进行解密，得到会话密钥。
对称加密通信：
- 客户端和服务器使用相同的会话密钥进行对称加密通信，提高数据传输的效率。

通过非对称加密完成密钥交换和身份验证，再结合对称加密进行高效的数据传输，HTTPS 保证了数据在传输过程中的安全性和完整性。

非对称加密，加密，解密，必须使用一个公开的公钥（public key）一个必须保护好的私钥（private key）。

公钥、私钥、成对出现，通过公钥加密的数据，只能用该私钥解密。

HTTPS协议

HTTPS协议不是单独的协议，而是基于HTTP+SSL或者HTTP+TLS的组合协议。

SSL 的全名是 Secure Sockets Layer  安全套接字层

TSL (Transport Layer Security） 安全传输层协议

作用

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1）所有信息都是加密传播，第三方无法窃听。

（2）具有校验机制，一旦被篡改，通信双方会立刻发现。

（3）配备身份证书，防止身份被冒充。

互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。

而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。

为什么需要HTTPS

不用HTTPS、纯HTTP的网站，就会面临数据包被恶意劫持、篡改；

改用HTTPS数据包在传输过程中被加密，黑客无法窃取，篡改，冒充；

HTTPS解析流程

1. 服务端有一对儿数字证书，包含私钥、公钥，也被称为CA证书，这个证书由专门的证书服务商提供，受互联网信任。（也可以自己创建CA证书，但是没人认。。）

2. 客户端发起https://请求，默认端口443

3. 服务端接收到请求后自动将自己的CA证书发给客户端

4. 客户端收到CA证书后，浏览器自动判断，是否在有效期内，是否受互联网信任，信任就是小绿锁，否则就是红色大叉。

5. 客户端如果验证证书通过、此时会【生成一个随机数】通过公钥对随机数加密

6. 客户端将这个【公钥加密后的随机数】发给服务端

7. 服务端接到这个【公钥加密后的随机数】后，使用自己的随机数解密，确认建立连接，后续的所有数据交互，通过这个随机数实现数据【对称加密】。

图解

HTTPS证书实践

购买平台

各大云厂商
阿里云 https://yundun.console.aliyun.com/
腾讯云  https://buy.cloud.tencent.com/ssl

查看其他公司怎么用证书

证书详细

颁发证书的机构

证书颁发机构（Certificate Authority，简称 CA）是负责发放和管理数字证书的权威机构，在网络安全领域起着至关重要的作用，以下为你介绍常见的证书颁发机构：

全球知名商业 CA

DigiCert
- 简介：全球最大的数字证书颁发机构之一，提供广泛的 SSL/TLS 证书、代码签名证书和文档签名证书等。
- 特点：其证书被全球各类浏览器和操作系统广泛信任，安全性能高，支持多种加密算法和密钥长度。很多大型企业、金融机构和电子商务网站都选择 DigiCert 的证书来保障网站的安全通信。
Symantec（现名 DigiCert 旗下品牌）
- 简介：曾经是数字证书市场的领导者，在网络安全领域具有很高的知名度。后来其证书业务被 DigiCert 收购。
- 特点：历史悠久，市场份额大，证书产品种类丰富。但由于过去出现过一些证书管理方面的问题，声誉受到一定影响。不过其技术实力依然强大，证书在市场上仍有较高的认可度。
Comodo（现名 Sectigo）
- 简介：以提供经济实惠且可靠的数字证书而闻名，服务于全球众多中小企业和个人用户。
- 特点：提供多种类型的 SSL 证书，包括单域名、多域名和通配符证书等。价格相对较为亲民，同时也注重用户体验，提供便捷的证书申请和管理流程。

国内知名 CA

中国金融认证中心（CFCA）
- 简介：经中国人民银行和国家信息安全管理机构批准成立的国家级权威安全认证机构，在金融行业具有广泛的应用。
- 特点：专注于金融领域的安全认证服务，为银行、证券、保险等金融机构提供数字证书服务，保障金融交易的安全和可靠。其证书在金融行业的认可度极高，具有严格的安全标准和规范的管理流程。
沃通 CA
- 简介：国内较早从事数字证书服务的 CA 机构，提供 SSL/TLS 证书、代码签名证书等多种类型的证书。
- 特点：注重技术研发和创新，积极推动国产密码算法在数字证书领域的应用。同时，沃通 CA 也提供优质的客户服务，在国内市场有一定的份额。

开源和非营利性 CA

Let's Encrypt
- 简介：一个非营利性的证书颁发机构，旨在为网站提供免费、自动化和开放的 SSL/TLS 证书，以促进互联网的安全和加密通信。
- 特点：证书完全免费，申请和部署过程简单自动化，大大降低了网站启用 HTTPS 的门槛。许多个人网站和小型企业网站选择 Let's Encrypt 的证书来实现网站的加密访问。不过，其证书有效期较短，通常为 90 天，需要定期更新。

证书类型与区别

数字证书是用于验证网络通信双方身份以及保障数据传输安全的电子文档，不同类型的证书在应用场景、验证级别和功能等方面存在差异，以下为你详细介绍常见的证书类型及其区别：

1. SSL/TLS 证书

SSL（Secure Sockets Layer）证书和 TLS（Transport Layer Security）证书本质上功能相同，TLS 是 SSL 的后续版本，它们主要用于保障网站数据传输的安全性，让用户可以安全地与网站进行交互。根据验证级别和覆盖范围，可进一步细分：

域名验证（DV）证书
- 验证方式：CA 机构仅验证域名的所有权，通常通过向域名注册时预留的邮箱发送验证邮件，或者在域名的 DNS 记录中添加特定的验证信息来完成验证。
- 特点：验证过程简单快速，一般几分钟到几小时内即可完成颁发。但验证级别较低，仅能证明该网站拥有该域名，无法证明网站背后的企业或组织的真实性。
- 适用场景：适用于个人博客、小型网站或测试环境等对安全验证要求不高的场景。
组织验证（OV）证书
- 验证方式：CA 机构除了验证域名所有权外，还会对申请组织的真实身份进行验证，包括核实组织的注册信息、联系方式等。
- 特点：验证级别较高，需要一定的时间来完成验证过程，通常需要 1 - 3 个工作日。颁发的证书会显示组织的名称，增强了用户对网站的信任度。
- 适用场景：适用于各类企业网站、电子商务平台等，能让用户更放心地与网站进行交互。
扩展验证（EV）证书
- 验证方式：这是最高级别的验证，CA 机构会对申请组织进行严格的全面审查，包括核实组织的法律地位、注册地址、经营范围等信息，甚至可能进行实地考察。
- 特点：验证过程最为严格和复杂，耗时较长，一般需要 3 - 5 个工作日。颁发的证书在浏览器地址栏会显示绿色的组织名称，给用户最直观的安全提示，极大地增强了用户对网站的信任。
- 适用场景：适用于金融机构、在线支付平台、政府网站等对安全性和信任度要求极高的场景。

2. 代码签名证书

作用：用于对软件代码、应用程序、脚本等进行签名，确保代码在传输和分发过程中没有被篡改，同时可以证明代码的开发者身份。
验证方式：CA 机构会对代码开发者的身份进行验证，包括核实开发者的个人信息或企业信息。
特点：可以提高软件的安全性和可信度，用户在下载和安装经过签名的软件时，系统会提示该软件的签名信息，让用户可以确认软件的来源和完整性。
适用场景：软件开发企业、独立开发者等在发布软件时使用，以增强用户对软件的信任，特别是在应用商店、软件下载平台等场景中应用广泛。

3. 电子邮件签名证书

作用：用于对电子邮件进行签名和加密，确保邮件内容的完整性和机密性，同时可以验证发件人的身份。
验证方式：CA 机构会对邮件用户的身份进行验证，通常需要用户提供有效的身份证明文件。
特点：可以防止邮件在传输过程中被篡改和窃取，保护邮件通信的安全。用户在接收经过签名和加密的邮件时，可以通过验证签名来确认邮件的真实性和完整性。
适用场景：适用于企业内部邮件通信、涉及敏感信息的邮件交流等场景，特别是金融、法律等对信息安全要求较高的行业。

4. 文档签名证书

作用：用于对电子文档（如 PDF、Word 等）进行签名，确保文档的完整性和真实性，同时可以证明签名者的身份。
验证方式：CA 机构会对签名者的身份进行验证，签名者需要提供有效的身份证明文件。
特点：可以防止文档在传输和存储过程中被篡改，具有法律效力，在电子合同、电子发票等场景中广泛应用。
适用场景：适用于企业间的商务合同签署、政府部门的文件审批等需要确保文档真实性和不可抵赖性的场景。

DV类型证书：中文全称是域名验证型证书，证书审核方式为通过验证域名所有权即可签发证书。此类型证书适合个人和小微企业申请，价格较低，申请快捷，但是证书中无法显示企业信息，安全性较差。在浏览器中显示锁型标志。

OV类型证书：中文全称是企业验证型证书，证书审核方式为通过验证域名所有权和申请企业的真实身份信息才能签发证书。目前OV类型证书是全球运用最广，兼容性最好的证书类型。此证书类型适合中型企业和互联网业务申请。在浏览器中显示锁型标志，并能通过点击查看到企业相关信息。支持ECC高安全强度加密算法，加密数据更加安全，加密性能更高。

EV类型证书：中文全称是增强验证型证书，证书审核级别为所有类型最严格验证方式，在OV类型的验证基础上额外验证其他企业的相关信息，比如银行开户许可证书。EV类型证书多使用于银行,金融,证券,支付等高安全标准行业。其在地址栏可以显示独特的EV绿色标识地址栏，最大程度的标识出网站的可信级别。支持ECC高安全强度加密算法，加密数据更加安全，加密性能更高。

DV、免费、个人证书
OV、企业级证书
EV、银行等高安全证书

腾讯、OV证书

OV SSL是 Organization Validation SSL 的缩写，指需要验证网站所有单位的真实身份的标准型SSL证书，此类证书也就是正常的SSL证书，不仅能起到网站机密信息加密的作用，而且能向用户证明网站的真实身份。所以，推荐在所有电子商务网站使用，因为电子商务需要的是在线信任和在线安全。

博客园DV证书

汇丰银行EV证书

域名匹配类型

在 SSL/TLS 证书中，域名匹配类型是一个重要概念，它决定了证书可以保护哪些域名和子域名。不同的域名匹配类型适用于不同的网站架构和安全需求。以下是常见的域名匹配类型：

1. 单域名证书（Single Domain Certificate）

定义：单域名证书仅能保护一个特定的域名。例如，证书颁发给 example.com，那么它只能用于保护该主域名，不能保护其子域名（如 sub.example.com）或其他域名。
特点
- 针对性强：专门为单个域名提供安全保障，适用于仅拥有一个主要域名且不需要保护子域名的网站。
- 价格相对较低：由于其保护范围有限，成本通常低于其他类型的证书。
适用场景：个人博客、小型企业网站等只需要保护单一域名的场景。

2. 多域名证书（Multi - Domain Certificate，也称为 SAN 证书）

定义：多域名证书可以同时保护多个不同的域名，这些域名可以是主域名，也可以是子域名，甚至可以是不同顶级域名下的域名。例如，一个多域名证书可以同时保护 example.com、sub.example.com 和 anotherdomain.net。
特点
- 灵活性高：可以将多个相关或不相关的域名整合在一个证书下，方便管理和维护。
- 节省成本：相比于为每个域名单独购买单域名证书，多域名证书可以降低总体成本。
适用场景：拥有多个相关业务域名的企业，如 company.com、company.cn 以及不同业务线的子域名；或者网站包含多个独立功能模块，每个模块使用不同域名的情况。

3. 通配符证书（Wildcard Certificate）

定义：通配符证书可以保护一个主域名及其所有的一级子域名。通配符使用 * 表示，例如，*.example.com 的通配符证书可以保护 sub1.example.com、sub2.example.com 等所有一级子域名，但不能保护二级子域名（如 sub.sub1.example.com）和主域名本身（example.com）。
特点
- 广泛覆盖：对于拥有大量子域名的网站，通配符证书可以提供便捷的安全保护，无需为每个子域名单独申请证书。
- 管理方便：只需管理一个证书，即可保障多个子域名的安全。
适用场景：大型企业网站、电子商务平台等拥有众多子域名的场景，如 store.example.com、blog.example.com 等。

4. 单域名通配符证书（Single Domain Wildcard Certificate）

定义：这种证书结合了单域名和通配符的特点，既可以保护主域名，又可以保护其所有一级子域名。例如，证书可以同时保护 example.com 和 *.example.com。
特点
- 全面保护：为单个域名及其子域名提供全面的安全覆盖，适用于对主域名和子域名都需要进行安全保护的情况。
- 成本相对较高：由于其保护范围更广，价格通常比普通通配符证书或单域名证书要高。
适用场景：对网站安全要求较高，需要同时保护主域名和大量子域名的企业或机构。

单域名证书  www.yuchaoit.cn

多域名证书   www.yuchaoit.cn  blog.yuchaoit.cn

通配符域名  *.yuchaoit.cn

DV证书购买注意事项

1. 一个通配符证书只支持二级域名

2. DV证书最多买3年，不支持续费，只能买新的

3. DV证书到期后浏览器告警不安全

4. 微信小程序、苹果商店等已经全面要求必须https

5.证书提前买，别突然到期了网站挂了，

实践购买阿里云证书（免费）

付费的证书，支持多域名匹配

免费的证书，只用于测试https，匹配单个域名

创建免费证书

申请证书

绑定域名

填写DNS验证

提交审核

下载证书（结合nginx部署）

接下来就是下载证书，交给nginx

用户访问网站时（nginx）会发送证书给客户端。

通过openssl命令检测证书过期时间

证书过期监控与 x509 证书管理指南

在运维场景中，证书过期是常见的高危故障原因之一。以下是针对证书过期监控及 x509 证书管理的详细方案：

一、证书关键信息解析（以 x509 为例）

x509 是 SSL/TLS 证书的通用标准格式，包含以下核心信息：

公钥与算法
- 公钥内容（如 RSA/ECDSA 公钥）。
- 签名算法（如 SHA256WithRSA）。
证书有效期
- 起始时间（Not Before）和过期时间（Not After）。
主体信息
- 合法拥有者的标识（Subject DN），如 CN=example.com, O=MyOrg。
用途扩展（Key Usage）
- 定义证书用途（如 TLS Web Server Authentication）。
颁发机构（Issuer）
- CA 的名称和签名。
CA 验证链
- 包含根证书、中间证书的校验链。

二、证书过期时间监控方法

1. 手动检查证书过期时间

# 使用 OpenSSL 检查证书文件（PEM 格式）
openssl x509 -in <证书文件> -noout -dates
# 输出示例：
# notBefore=Jan 1 00:00:00 2023 GMT
# notAfter=Jan 1 00:00:00 2024 GMT

# 检查远程服务的证书（如 API Server）
openssl s_client -connect <域名或IP>:<端口> -servername <域名> 2>/dev/null | openssl x509 -noout -dates

2. 自动化监控脚本示例

#!/bin/bash
CERT_FILE="/path/to/cert.pem"
EXPIRY_DATE=$(openssl x509 -in $CERT_FILE -enddate -noout | cut -d= -f2)
EXPIRY_SECONDS=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_SECONDS=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_SECONDS - CURRENT_SECONDS) / 86400 ))

if [ $DAYS_LEFT -lt 30 ]; then
  echo "警报: 证书将在 $DAYS_LEFT 天后过期！"
  # 触发告警（邮件、Slack、Prometheus 等）
fi

脚本监控证书过期时间


server_name=www.yuchaoit.com

# 获取网站的证书有效期
ssl_time=$(echo | openssl s_client -servername ${server_name}  -connect ${server_name}:443 2>/dev/null | openssl x509 -noout -dates|awk -F '=' '/notAfter/{print $2}')

# 转换时间戳
ssl_unix_time=$(date +%s -d "${ssl_time}")

# 获取今天时间戳
today=$(date +%s)

# 计算剩余时间

let  expr_time=($ssl_unix_time-$today)/24/3600

echo "${server_name} 该ssl证书剩余时间：$expr_time"

图解证书

下面为你详细介绍 HTTPS 证书相关流程，并使用 Mermaid 绘制对应的流程图。

HTTPS 证书工作流程概述

HTTPS 证书的主要作用是确保客户端与服务器之间通信的安全性和数据完整性。其基本工作流程如下：

服务器生成密钥对：服务器生成一对公私钥，公钥用于加密数据，私钥用于解密数据。
申请证书：服务器将公钥和一些其他信息（如域名等）发送给证书颁发机构（CA），申请数字证书。
CA 验证与签名：CA 对服务器提供的信息进行验证，验证通过后，使用自己的私钥对服务器的公钥和相关信息进行签名，生成数字证书。
客户端验证证书：客户端向服务器发起请求，服务器返回数字证书。客户端使用 CA 的公钥验证证书的有效性。
建立安全连接：验证通过后，客户端和服务器使用会话密钥进行加密通信。

Mermaid 代码

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(服务器生成密钥对):::process
    B --> C(服务器申请证书):::process
    C --> D(证书颁发机构 CA):::process
    D --> E{CA 验证信息}:::decision
    E -->|验证通过| F(CA 使用私钥签名):::process
    E -->|验证失败| G([结束]):::startend
    F --> H(生成数字证书):::process
    H --> I(服务器接收证书):::process
    I --> J(客户端发起请求):::process
    J --> K(服务器返回证书):::process
    K --> L(客户端使用 CA 公钥验证证书):::process
    L --> M{证书是否有效}:::decision
    M -->|是| N(建立安全连接):::process
    M -->|否| O([结束]):::startend
    N --> P(客户端和服务器加密通信):::process
    P --> Q([结束]):::startend

代码解释

开始：流程的起始点。
服务器生成密钥对：服务器生成公钥和私钥。
服务器申请证书：服务器将公钥和相关信息发送给 CA。
CA 验证信息：CA 对服务器提供的信息进行验证。
CA 使用私钥签名：如果验证通过，CA 使用自己的私钥对服务器的公钥和相关信息进行签名。
生成数字证书：签名后生成数字证书。
服务器接收证书：服务器接收 CA 颁发的数字证书。
客户端发起请求：客户端向服务器发起 HTTPS 请求。
服务器返回证书：服务器将数字证书返回给客户端。
客户端使用 CA 公钥验证证书：客户端使用 CA 的公钥验证证书的有效性。
证书是否有效：判断证书是否有效。
建立安全连接：如果证书有效，客户端和服务器建立安全连接。
客户端和服务器加密通信：使用会话密钥进行加密通信。
结束：流程结束。

这个 Mermaid 图清晰地展示了 HTTPS 证书从生成到验证，再到建立安全连接和加密通信的整个过程。

一、nginx实战配置https

1.获取证书（阿里云申请、自建）

1.可以去阿里云申请免费单域名证书，下载使用
部署文档
https://help.aliyun.com/document_detail/98728.html?spm=5176.b657008.help.dexternal.7b14799daFqyjG


2.自己创建私有证书，内网环境下使用。

2.自建证书

以下是自建HTTPS证书并部署到Nginx的详细步骤：

1. 安装OpenSSL工具

确保系统已安装OpenSSL（大多数Linux系统已预装）：

sudo apt-get update && sudo apt-get install openssl  # Debian/Ubuntu
sudo yum install openssl                             # CentOS/RHEL

2. 创建证书存放目录

创建目录存放SSL证书和私钥，并设置权限：

sudo mkdir -p /etc/nginx/ssl
sudo chmod 700 /etc/nginx/ssl

3. 生成自签名证书

方法一：快速生成（无SAN扩展）

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/nginx/ssl/server.key \
    -out /etc/nginx/ssl/server.crt \
    -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=example.com"

参数说明：
- -x509：生成自签名证书。
- -nodes：私钥不加密（避免Nginx重启需输入密码）。
- -days 365：证书有效期（天）。
- -newkey rsa:2048：生成2048位RSA私钥。
- -subj：证书信息（CN必须为域名或IP，如example.com）。

方法二：包含SAN扩展（多域名/IP支持）

创建配置文件 san.cnf：

 [req]
 req_extensions = v3_req
 distinguished_name = req_distinguished_name
 prompt = no

 [req_distinguished_name]
 CN = example.com

 [v3_req]
 keyUsage = keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth
 subjectAltName = @alt_names

 [alt_names]
 DNS.1 = example.com
 DNS.2 = www.example.com
 IP.1 = 192.168.1.1

生成证书：

 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
     -keyout /etc/nginx/ssl/server.key \
     -out /etc/nginx/ssl/server.crt \
     -config san.cnf -extensions v3_req

4. 配置Nginx使用SSL

编辑Nginx配置文件（如/etc/nginx/sites-available/default或自定义配置文件）：

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # 推荐SSL配置（增强安全性）
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # 其他配置（如网站根目录）
    root /var/www/html;
    index index.html;
}

# 可选：HTTP重定向到HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

5. 设置文件权限

确保私钥和证书权限安全：

sudo chown root:root /etc/nginx/ssl/*
sudo chmod 600 /etc/nginx/ssl/server.key   # 私钥仅允许root读取
sudo chmod 644 /etc/nginx/ssl/server.crt   # 证书可公开读取

6. 解决SELinux问题（仅限CentOS/RHEL）

若系统启用SELinux，需调整文件上下文：

sudo chcon -R -t httpd_sys_content_t /etc/nginx/ssl/

7. 测试配置并重启Nginx

sudo nginx -t          # 检查配置语法
sudo systemctl restart nginx   # 重启生效

8. 防火墙放行HTTPS

sudo ufw allow 443/tcp        # 使用UFW（Ubuntu）
sudo firewall-cmd --permanent --add-service=https && firewall-cmd --reload  # FirewallD（CentOS）

9. 浏览器访问测试

访问 https://example.com，浏览器将提示证书不受信任（因自签名）。
手动信任证书：
1. 导出 server.crt 并导入到客户端系统的“受信任的根证书颁发机构”。
2. 或点击浏览器警告页面的“高级”->“继续访问”。

常见问题

证书域名不匹配：确保生成证书时 CN 或 SAN 包含访问的域名/IP。
Nginx启动失败：检查证书路径和权限，使用 nginx -t 排查配置错误。
SELinux阻止访问：使用 audit2why 分析日志，调整策略。

通过以上步骤，您已成功创建自签名HTTPS证书并部署到Nginx。此证书适用于测试或内部环境，生产环境建议使用受信任的CA（如Let's Encrypt）签发证书。

3.设置nginx

nginx.conf主配置文件

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}
~

ssl.conf

自动跳转https设置

server {
    listen 80;
    server_name www.yuchaoit.cn;
    rewrite ^(.*) https://$server_name$1 redirect;
}

server{
    listen 443 ssl;
    server_name www.yuchaoit.cn;
  ssl_certificate ssl_key/server.crt;
  ssl_certificate_key ssl_key/server.key;

  location / {
          root /www;
          index index.html;
  }
}

4.启动nginx（https）

# 创建测试数据
mkdir -p /www

cat >/www/index.html <<EOF
<meta charset=utf8>
超哥带你学nginx https ，我是web-7机器
EOF


systemctl restart nginx

5.访问nginx

本地做好域名解析

10.0.0.7 www.yuchaoit.cn

二、nginx集群配置https（web-7，web-8）

嗯，用户现在想实现全站、前后端以及通过Nginx反向代理来配置HTTPS。之前的问题是关于自建证书并部署到Nginx，现在用户的需求扩展到了整个架构的HTTPS配置。我需要仔细分析用户的需求，确保覆盖所有必要的步骤，并且考虑到可能的潜在问题。

首先，用户提到“全站HTTPS”，这意味着所有HTTP流量都应该重定向到HTTPS。这通常需要在Nginx配置中添加一个HTTP的server块，返回301重定向到HTTPS。之前的回复已经包括了这部分，但可能需要再次强调或检查是否正确配置。

接下来是“前后端”的HTTPS。这里可能有两种情况：前后端分离部署，前端可能是一个静态站点（比如React或Vue应用），后端是API服务（比如Node.js、Spring Boot或Django）。用户希望前后端都通过HTTPS访问，并且可能通过Nginx反向代理来连接后端服务。这时候需要确保Nginx不仅处理前端请求，还要正确代理到后端服务的HTTPS端口，或者后端服务本身是否也需要配置HTTPS？或者用户可能指的是后端服务虽然运行在内部网络，但通过Nginx暴露到外部时使用HTTPS？

另外，反向代理的情况下，Nginx和后端服务之间的通信是否需要加密？通常情况下，如果后端服务运行在同一台服务器或内部网络中，可能不需要HTTPS，而是使用HTTP，然后由Nginx终止SSL，处理HTTPS到客户端的通信，然后以HTTP代理到后端。但用户可能希望前后端之间的通信也加密，这就需要后端服务启用HTTPS，并且Nginx配置为使用HTTPS连接后端，但这会增加复杂性和性能开销，需要权衡。

然后，自签名证书的问题。用户之前的问题是关于自签证书，但这里可能需要考虑是否适用于生产环境。自签名证书适合测试或内部使用，但生产环境应使用受信任的CA颁发的证书，比如Let's Encrypt。不过用户可能仍希望使用自签证书，所以需要指导如何在各个部分正确部署。

另外，反向代理配置中需要注意的头部设置，比如Host、X-Real-IP、X-Forwarded-For等，以确保后端服务能正确获取客户端信息。同时，可能需要处理WebSocket的代理，如果前端应用使用了WebSocket，这需要额外的配置。

还有，前端和后端的静态文件路径配置是否正确，反向代理的路径匹配是否正确，比如前端路由是否需要使用try_files来避免404错误，或者后端API的路径是否正确代理。

安全方面，除了基本的SSL配置，可能需要加强SSL协议和加密套件的选择，禁用不安全的协议如TLS 1.0和1.1，使用更安全的TLS 1.2和1.3。同时，配置HSTS头以增强安全性，防止SSL剥离攻击。

此外，证书的信任问题。自签名证书在浏览器中会显示警告，用户可能需要指导如何将证书导入到受信任的根证书颁发机构，尤其是在内部系统中使用时。或者建议用户在生产环境中使用Let's Encrypt，以避免信任问题。

可能还需要考虑负载均衡的情况，如果后端有多个实例，如何配置Nginx的upstream模块进行负载均衡，并且是否启用健康检查。

最后，测试步骤非常重要。需要确保用户完成配置后，检查前端HTTPS是否生效，后端API是否通过HTTPS正确代理，HTTP是否被正确重定向，以及所有安全头是否正确设置。使用工具如SSL Labs的测试来评估SSL配置的安全性。

总结起来，用户的场景可能涉及以下步骤：

为全站配置HTTP到HTTPS的重定向。
前端静态文件的HTTPS服务配置。
后端API服务的反向代理配置，终止SSL在Nginx，然后以HTTP或HTTPS与后端通信。
配置SSL证书，可能是自签名或Let's Encrypt。
安全强化，如SSL协议、加密套件、HSTS等。
处理前后端路由和代理路径，确保无404错误。
设置正确的HTTP头部，以便后端获取真实客户端IP和其他信息。
测试和调试配置，解决可能的问题。

需要确保每个步骤都详细说明，尤其是反向代理部分的配置，以及前后端如何协同工作。同时，提醒用户注意自签名证书的局限性，并建议生产环境使用可信证书。

以下是实现全站HTTPS、前后端分离及Nginx反向代理的完整配置流程，涵盖证书生成、前端部署、后端代理及安全优化：

1. 整体架构

客户端 (HTTPS) → Nginx (SSL Termination)
                   ├── 代理静态前端（如Vue/React）
                   └── 反向代理动态后端（如Node.js/Spring Boot）

2. 生成证书（自签名或Let's Encrypt）

2.1 自签名证书（测试环境）

# 生成CA根证书（用于客户端信任自签名证书）
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj "/CN=My CA"

# 生成服务端证书（包含前端和后端域名/IP）
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=example.com"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -extfile <(echo "subjectAltName=DNS:example.com,DNS:api.example.com,IP:192.168.1.1")

2.2 Let's Encrypt证书（生产环境推荐）

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d api.example.com

3. Nginx反向代理配置

3.1 全站HTTPS强制跳转

# HTTP → HTTPS 全局跳转
server {
    listen 80;
    server_name example.com api.example.com;
    return 301 https://$host$request_uri;
}

3.2 前端静态资源服务

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # 安全强化配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # 前端静态文件配置
    root /var/www/frontend/dist;
    index index.html;

    # 处理前端路由（如Vue/React的history模式）
    location / {
        try_files $uri $uri/ /index.html;
    }
}

3.3 后端API反向代理

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # 代理到后端服务（假设后端运行在localhost:8080）
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket支持
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

4. 后端服务配置示例

4.1 Spring Boot（application.properties）

server.port=8080
# 确保后端不强制HTTPS（由Nginx终止SSL）

4.2 Node.js（Express）

const express = require('express');
const app = express();
app.use(express.json());

app.get('/api/data', (req, res) => {
    res.json({ message: "Data from HTTPS backend" });
});

app.listen(8080, () => {
    console.log('Backend running on HTTP (Nginx handles HTTPS)');
});

5. 安全加固

5.1 配置文件权限

sudo chown root:root /etc/nginx/ssl/*
sudo chmod 600 /etc/nginx/ssl/server.key
sudo chmod 644 /etc/nginx/ssl/server.crt

5.2 防火墙规则

sudo ufw allow 443/tcp
sudo ufw deny 80    # 生产环境可彻底关闭HTTP

5.3 禁用不安全的TLS协议

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

6. 验证与测试

证书有效性检查：

curl -vI https://example.com
openssl s_client -connect example.com:443 -servername example.com

前端访问测试：
- 浏览器访问 https://example.com，确认无混合内容警告。

API接口测试：

curl -k https://api.example.com/api/data  # -k 参数跳过自签名证书验证

SSL Labs评分：
- 访问 SSL Server Test 输入域名检查安全评级。

7. 常见问题排查

7.1 502 Bad Gateway

检查后端服务是否运行：systemctl status backend-service
确认Nginx的proxy_pass地址和端口正确

7.2 混合内容警告

前端代码中确保所有资源（图片、CSS、JS）使用https://链接

7.3 证书不信任

自签名证书需将ca.crt导入客户端系统信任链
生产环境务必使用Let's Encrypt证书

8. 扩展：负载均衡配置

若后端多实例部署，可在Nginx中配置upstream：

http {
    upstream backend {
        server 127.0.0.1:8080 weight=1;
        server 192.168.1.2:8080 weight=2;  # 权重负载
        least_conn;                         # 最少连接策略
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

通过以上步骤，可实现全站HTTPS、前后端分离及Nginx反向代理的安全部署，适用于测试和生产环境。

情况1，全站https通信

1.部署web-8

# 证书发送
[root@web-7 /etc/nginx/conf.d]#cd /etc/nginx/
[root@web-7 /etc/nginx]#ls
conf.d  fastcgi_params  mime.types  modules  nginx.conf  scgi_params  ssl_key  uwsgi_params
[root@web-7 /etc/nginx]#
[root@web-7 /etc/nginx]#scp -r ssl_key 10.0.0.8:/etc/nginx/

# 配置文件发送
[root@web-7 /etc/nginx]#scp -r conf.d/ssl.conf 10.0.0.8:/etc/nginx/conf.d/


# 网页文件创建
mkdir -p /www

cat >/www/index.html <<EOF
<meta charset=utf8>
超哥带你学nginx https ，我是web-8机器
EOF


systemctl restart nginx

2.部署lb机器

# 获取统一的证书
scp -r ssl_key 10.0.0.5:/etc/nginx/

# 创建反向代理配置文件
upstream ssl_pools {
    server 172.16.1.7:443;
    server 172.16.1.8:443;
}

# 80虚拟主机，目的是为了匹配http请求的80端口，强制转发给https的443端口
server {
    listen 80;
    server_name www.yuchaoit.cn;
    rewrite ^(.*) https://$server_name$1 redirect;
}

server {
    # 注意端口号，协议；
    listen 443 ssl;
    server_name www.yuchaoit.cn;

  ssl_certificate ssl_key/server.crt;
  ssl_certificate_key ssl_key/server.key;
  # 反向代理
  location / {
            proxy_pass https://ssl_pools;
            include proxy_params;
  }
}


# 反向代理参数文件
# cat proxy_params 
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 4 128k;


# 检测语法，重启
[root@lb-5 /etc/nginx]#nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@lb-5 /etc/nginx]#systemctl restart nginx

3.测试https集群访问

客户端做好dns解析
10.0.0.5 www.yuchaoit.cn

先手动测试web服务器是否可以访问

测试负载均衡的转发

情况二：lb负责https外网加密，后端web内网简化无须证书

1.部署lb机器

注意要修改后端节点的端口、以及转发的http协议。

[root@lb-5 /etc/nginx/conf.d]#vim ssl.conf 
[root@lb-5 /etc/nginx/conf.d]#cat ssl.conf 
upstream ssl_pools {
    server 172.16.1.7;
    server 172.16.1.8;
}

# 80虚拟主机，目的是为了匹配http请求的80端口，强制转发给https的443端口
server {
    listen 80;
    server_name www.yuchaoit.cn;
    rewrite ^(.*) https://$server_name$1 redirect;
}

server {

    listen 443 ssl;
    server_name www.yuchaoit.cn;

  ssl_certificate ssl_key/server.crt;
  ssl_certificate_key ssl_key/server.key;
  # 反向代理
  location / {
            proxy_pass http://ssl_pools;
            include proxy_params;
  }
}

2.部署web机器组7,8

web-7

[root@web-7 /etc/nginx]#cat conf.d/ssl.conf 
server {
    listen 80;
    server_name www.yuchaoit.cn;
  location / {
                root /www;
                index index.html;
  }

}

# 重启
systemctl restart nginx

web-8

[root@web-8 /etc/nginx/conf.d]#cat ssl.conf 
server {
    listen 80;
    server_name www.yuchaoit.cn;
  location / {
                root /www;
                index index.html;
  }

}

# 重启
systemctl restart nginx

3.测试访问

4.测试负载均衡

三、wordpress支持https

需要开启fastcgi转发参数，支持https

1.lb服务器设置

[root@lb-5 /etc/nginx/conf.d]#cat wordpress.conf 
upstream wordpress_pools {
    server 172.16.1.7;
    server 172.16.1.8;
}

# 80虚拟主机，目的是为了匹配http请求的80端口，强制转发给https的443端口
server {
    listen 80;
    server_name wordpress.yuchaoit.cn;
    rewrite ^(.*) https://$server_name$1 redirect;
}

server {

    listen 443 ssl;
    server_name wordpress.yuchaoit.cn;

  ssl_certificate ssl_key/server.crt;
  ssl_certificate_key ssl_key/server.key;
  # 反向代理
  location / {
            proxy_pass http://wordpress_pools;
            include proxy_params;
  }
}

2.web机器组

两台web机器都要设置代理参数，让nginx+php的代理参数，支持https。

fastcgi_params参数(两台机器)

[root@web-8 /etc/nginx]#
[root@web-8 /etc/nginx]#cat fastcgi_params 

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

# enable https
fastcgi_param HTTPS on;

nginx配置文件设置(wordpress，两台机器)

[root@web-8 /etc/nginx/conf.d]#ls
ssl.conf.bak  wordpress.conf
[root@web-8 /etc/nginx/conf.d]#
[root@web-8 /etc/nginx/conf.d]#cat wordpress.conf 
server {
    listen 80;
    server_name wordpress.yuchaoit.cn;
    root /code/wordpress/;
    index index.php index.html;

    location ~ \.php$ {

        root /code/wordpress;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

}

重启

[root@web-8 /etc/nginx/conf.d]#nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@web-8 /etc/nginx/conf.d]#systemctl restart nginx

启动php后端

systemctl restart php-fpm

3.测试访问lb入口

dns解析

10.0.0.5 www.yuchaoit.cn wordpress.yuchaoit.cn

4.访问结果

5. 日志检测（两个web机器）

web-7、web-8

四、阿里云https证书免费申请

部署阿里云公网https测试...步骤和上述一样。

PHP后端https架构

1. 生成证书

sudo mkdir -p /etc/nginx/ssl
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/nginx/ssl/server.key \
    -out /etc/nginx/ssl/server.crt \
    -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=yourdomain.com"

关键参数：
- -subj：直接指定证书的CN（Common Name），此处必须填写实际域名（如yourdomain.com）.
- 不添加-addext或-extfile参数，避免包含SAN扩展.

2. Nginx配置示例

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # 安全配置（推荐）
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    root /var/www/html;
    index index.php index.html;

    # PHP处理
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # 强制HTTP跳转HTTPS
    error_page 497 https://$host$request_uri;
}

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

3. 验证与注意事项

浏览器警告处理：
- 自签名证书无SAN扩展时，浏览器会提示“证书的CN不匹配”，需手动确认访问。
- 必须确保证书的CN字段（yourdomain.com）与访问的域名完全一致.
检查证书信息：
```
openssl x509 -in /etc/nginx/ssl/server.crt -text -noout
```
- 确认输出中没有X509v3 Subject Alternative Name字段.
PHP后端兼容性：
- 确保PHP代码中所有链接使用https://或协议自适应路径（如//yourdomain.com/resource.jpg）.

4. 生产环境替代方案

若需消除浏览器警告，建议使用Let's Encrypt免费证书（自动包含SAN）：

sudo certbot --nginx -d yourdomain.com

常见问题

错误提示“SSL_ERROR_BAD_CERT_DOMAIN”：
- 原因：访问域名与证书CN不匹配。
- 解决：重新生成证书，确保-subj中的CN与域名一致。

Nginx无法读取证书：

sudo chmod 644 /etc/nginx/ssl/server.crt
sudo chmod 600 /etc/nginx/ssl/server.key

通过以上步骤，您已成功部署不带SAN扩展的自签名HTTPS证书。适用于测试或内部网络，生产环境建议使用受信任的CA证书。