一种基于openresty的动态证书代理方法技术

本发明专利技术提供了一种基于openresty的动态证书代理方法，属于Web通信技术领域，它解决了代理服务器端口重用的技术问题。本基于openresty的动态证书代理方法，通过以下步骤实现：S1、通过TLS/SSL握手过程中的clientHello信息获取到客户端发送到服务端的sni信息；S2、根据获取到的sni信息查找对应服务器的证书和密钥；S3、将证书和密钥配置进web服务器；S4、与客户端进行TLS/SSL握手时返回新配置的证书。本发明专利技术具有减轻了系统的复杂度，增加了便利性及可维护性的优点。增加了便利性及可维护性的优点。增加了便利性及可维护性的优点。

【技术实现步骤摘要】
一种基于openresty的动态证书代理方法


[0001]本专利技术属于Web通信
，涉及一种基于openresty的动态证书代理方法。

技术介绍

[0002]当进行TLS连接时，客户端从Web服务器请求数字证书。服务器一旦发送证书，客户端就会检查这个证书，并将其尝试连接的名称与证书中包含的名称进行对比。如果发生匹配，则连接正常进行。如果没有找到匹配，则可能会向用户警告该差异，并且可能会中止连接，因为该失配可能表明存在中间人攻击。不过，某些应用程序允许用户绕过警告继续进行连接，由用户承担信任证书以及连接的责任。
[0003]一个证书覆盖多个主机名是可以做到的。X.509v3规范引入了subjectAltName字段，该字段允许一个证书指定多个域名，并在通用名和subjectAltName字段中使用通配符。
[0004]Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，在BSD
‑
like协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好。因为在nginx的stream中，同一个 server上下文监听的端口只能配置一对证书与密钥，但是在一些使用场景中，如果想要根据不同的访问地址返回相对应的证书，就需要在nginx的配置文件中多个server，并且不能解决端口复用的问题。
[0005]然而，由于缺少所有名称的完整列表，可能很难甚至不可能获得涵盖服务器将负责的所有名称的单个证书。负责多个主机名的服务器可能需要为每个名称(或一组名称)提供不同的证书。自2005年以来，CAcert已经在虚拟服务器上运行了TLS的不同用法的实验。大多数实验是不理想和不切实际的。例如，可以使用subjectAltName来包含单个证书中由一个人控制的多个域名。每当域名列表更改时，必须重新发布此类“统一通信证书”。
[0006]基于名称的虚拟主机允许多个DNS主机名由同一IP地址上的单个服务器(通常为Web服务器)托管。为了实现这一点，服务器使用客户端提供的主机名作为协议的一部分(对于HTTP，名称显示在主机头中)。但是，当使用HTTPS时，TLS握手发生在服务器看到任何HTTP头之前。因此，服务器不可能使用HTTP主机头中的信息来决定呈现哪个证书，因此只有由同一证书覆盖的名称才能由同一IP地址提供。

技术实现思路

[0007]本专利技术的目的是针对现有的技术存在上述问题，提出了一种基于openresty的动态证书代理方法，本专利技术解决了代理服务器端口重用的问题，可以使用同一端口代理不同的站点，并配置不同的证书。
[0008]本专利技术的目的可通过下列技术方案来实现：
[0009]一种基于openresty的动态证书代理方法，其特征在于，通过以下步骤实现：
[0010]S1、通过TLS/SSL握手过程中的clientHello信息获取到客户端发送到服务端的sni信息；
[0011]S2、根据获取到的sni信息查找对应服务器的证书和密钥；
[0012]S3、将证书和密钥配置进web服务器；
[0013]S4、与客户端进行TLS/SSL握手时返回新配置的证书。
[0014]进一步的，TLS/SSL握手过程如下：
[0015](1)客户端向服务器发送ClientHello消息；
[0016](2)对于客户端发送的ClientHello消息，服务器会返回一个ServerHello消息；
[0017](3)服务器发送Certificate消息，客户端会对服务器发过来的证书进行验证；
[0018](4)服务器发送ServerKeyExchange消息；
[0019](5)服务器发送ServerHelloDone消息；
[0020](6)客户端发送ClientKeyExchange消息；
[0021](7)客户端和服务器进行报文交换，使用步骤(6)协商后的密钥加密。
[0022]进一步的，在步骤(1)中，客户端需要和服务器进行协商，具体使用何种方式来通信。
[0023]进一步的，在步骤(2)中，服务器返回的ServerHello消息会告知客户端采用的通信方式。
[0024]进一步的，在步骤(3)中，服务器同时可以选择是否发送 CertificateRequest消息；CertificateRequest消息用于服务器向客户端请求证书，这是为了进行客户端认证，当不使用客户端认证时，不会发送CertificateRequest消息。
[0025]进一步的，当步骤(3)中服务器发送CertificateRequest 消息时，客户端会将自己的证书同Certificate消息一起发送给服务器；当服务器没有发送CertifacateRequest消息时，客户端不会发送Certificate消息。
[0026]进一步的，在步骤(4)中，当Certificate消息不足以满足需求时候，服务器会通过ServerKeyExchange消息向客户端发送一些必要信息，具体发送的信息内容会根据所使用的密码套件而有所不同，当不需要这些信息时候，将不会发送 ServerKeyExchange消息。
[0027]进一步的，在步骤(5)中，ServerHelloDone这一消息表示从ServerHello消息开始的一系列消息的结束。
[0028]与现有技术相比，本基于openresty的动态证书代理方法具有以下优点：
[0029]本专利技术不需要证书包含全部域名，只需要根据请求的目的域名返回对应的证书，减轻了系统的复杂度，增加了便利性及可维护性。
附图说明
[0030]图1是本专利技术的工作流程图。
[0031]图2是本专利技术中ssl握手流程图。
[0032]图3是本专利技术中clienthello信息中的sni信息。
具体实施方式
[0033]以下是本专利技术的具体实施例并结合附图，对本专利技术的技术方案作进一步的描述，但本专利技术并不限于这些实施例。
[0034]如图1所示，本实施例提供一种基于openresty的动态证书代理方法，通过以下步
骤实现：
[0035]S1、通过TLS/SSL握手过程中的clientHello信息获取到客户端发送到服务端的sni信息；
[0036]S2、根据获取到的sni信息查找对应服务器的证书和密钥；
[0037]S3、将证书和密钥配置进web服务器；
[0038]S4、与客户端进行TLS/SSL握手时返回新配置的证书。
[0039]进一步的，TLS/SSL握手过程如下：
[0040](1)客户端向服务器发送ClientHello消息；
[0041](2)对于客户端发送的ClientHello消息，服务器会返回一个ServerHello消息；
[0042](3)服本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种基于openresty的动态证书代理方法，其特征在于，通过以下步骤实现：S1、通过TLS/SSL握手过程中的clientHello信息获取到客户端发送到服务端的sni信息；S2、根据获取到的sni信息查找对应服务器的证书和密钥；S3、将证书和密钥配置进web服务器；S4、与客户端进行TLS/SSL握手时返回新配置的证书。2.根据权利要求1所述的一种基于openresty的动态证书代理方法，其特征在于，TLS/SSL握手过程如下：(1)客户端向服务器发送ClientHello消息；(2)对于客户端发送的ClientHello消息，服务器会返回一个ServerHello消息；(3)服务器发送Certificate消息，客户端会对服务器发过来的证书进行验证；(4)服务器发送ServerKeyExchange消息；(5)服务器发送ServerHelloDone消息；(6)客户端发送Cl ientKeyExchange消息；(7)客户端和服务器进行报文交换，使用步骤(6)协商后的密钥加密。3.根据权利要求2所述的一种基于openresty的动态证书代理方法，其特征在于，在步骤(1)中，客户端需要和服务器进行协商，具体使用何种方式来通信。4.根据权利要求2所述的一种基于openresty的动态证书代理方法，其特征在于，在步骤(2)中，服务器返回的ServerHello消息会告知客户端采用的通...

【专利技术属性】
技术研发人员：刘庆林，
申请(专利权)人：山东中睿天下信息技术有限公司，
类型：发明
国别省市：