一种传统SSL申请流程兼容ACME的方法与流程

一种传统ssl申请流程兼容acme的方法
技术领域
1.本发明涉及网络通信安全技术领域，具体为一种传统ssl申请流程兼容acme的方法。


背景技术：

2.acme作为isrg创立的致力于提供tls自动化的标准，其近乎完美的实现了数字证书的申请、验证、签发、安装以及续期的自动化；然而由于其设计之初的局限性，acme在推广过程中，行业从业者慢慢发现其逐渐成为了非全行业可以参与的游戏，有且只有ca才能设计、研发、并提供acme的服务；而代理商以及有tls需求的idc业者，因acme与传统ssl申请流程不兼容的原因被无情的拒绝在了acme大门之外。
3.ssl与acme的不兼容性主要表现在三方面：其一为验证和csr提交流程的不兼容，传统的ssl的申请为先进行csr提交后进行域名验证，而acme为先进行域名验证后进行csr提交；其次为域名验证方式不兼容，传统的ssl在进行dns验证是能够解析_dnsauth或、_《md5》或者@，在http验证时上传的路径为.well-known/pki-validation/《file》，而acme进行dns验证只能解析_acme-challenge，在http验证时上传的路径为.well-known/acme-challenge/《token》；再次为acme中间人防御机制，导致ssl分销商通过传统对接接口，无法提供acme自动化，基于上述的不兼容点导致acme无法与ssl兼容使用。


技术实现要素：

4.本发明的目的在于提供一种传统ssl申请流程兼容acme的方法，以解决上述背景技术中提出的问题。
5.为实现上述目的，本发明提供如下技术方案：一种传统ssl申请流程兼容acme的方法，包括该方法包括以下步骤：
6.步骤一：下单，启动acme.sh，后按照acme(rfc8555标准)流程进入下单步骤，将域名清单发送至acme的neworder接口；
7.步骤二：提交csr，获取orderobjects和authorizationobjects，并在获取authorizationobjects时候，我们对challenges中所有的token字段进行特殊处理；
8.步骤三：域名验证，acme服务器使用了“|bash-s”管道返回域名的验证执行命令，进行域名验证；
9.步骤四：签发，客户端调用acme的finalize接口去执行ca的检查域名验证接口实现证书的验证操作。
10.所述步骤三中type具有dns-01和http-01两种类型，特殊处理的内容包括将类型为为dns-01的token里面，”提交csr”的url返回的内容需要有以下指令：dns_《dns提供商》_add《dns主机名称》《dns解析值》；将类型为为http-01的token里面，”提交csr”的url返回的内容需要有以下指令：mkdir-p
″
《目录》/.well-known/pki-validation
″
。
11.更进一步地，所述步骤一中的域名清单包括普通域名、通配符、ip和ipv6地址中的
一种。
12.更进一步地，所述步骤三中返回的两种类型token需要对其中的空格应用｀ifs＝^；cmd＝base64^-\d；$cmd《《《ia＝＝`替代。
13.更进一步地，所述步骤三中返回的两种类型token需要对其中的：//用$(ifs＝^；cmd＝base64^-d；$cmd《《《oi8v)替代。
14.更进一步地，所述步骤四中，acme服务器会忽略客户端发来的csa。
15.与现有技术相比，本发明的有益效果是：
16.该传统ssl申请流程兼容acme的方法，利用acme.sh协议客户端会执行challenges中token被#分割后第四段指令的特性，直接绕过，让acme.sh先提交csr并完成ca要求的域名验证，由此解决acme对csr提交顺序以及域名验证的兼容问题的。
17.同时，利用修改后的token，对验证的路径进行更改，从而让acme的上传路径从而.well-known/acme-challenge/《token》更改为与ssl兼容的.well-known/pki-validation中，从而解决域名验证方式不兼容。
18.同理，通过修改后的token，对解析命令进行覆盖，从而解决传统的ssl在进行dns验证时能解析_dnsauth、_《md5》、@；而acme进行dns验证只能解析_acme-challenge导致不兼容的问题。
19.最后，因为修改了验证机制完全接入了传统ssl的域名验证方法，ca收到证书请求时，所下单的方式与传统ssl没有差异，不再要求acme标准的需要验证客户端account key的解析方式(或文件验证方式)，从而解决acme中间人防御机制，导致ssl分销商通过传统接口无法提供acme自动化，基于上述的不兼容点导致acme无法与ssl兼容使用的问题。
附图说明
20.图1为本发明方法的原理图。
具体实施方式
21.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
22.需要说明的是，在本发明的描述中，主要应用与客户端与服务器的信息交互验证，其中信息的收发验证均依靠外网或者将局域内网完成，其中的服务器内部的验证方式和执行方式，依靠服务器系统自行指令以及acme的运行规范自动执行，对配置文件的编辑依靠命令行或者文本编辑其进行，其均为行业内部的常规配置手段。
23.应注意的是，相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义或说明，则在随后的附图的说明中将不需要再对其进行进一步的具体讨论和描述。
24.近年来ssl证书寿命从之前的5年，缩短至3年，再到2年，到现在1年，按照行业趋势以后会进一步缩短。传统ssl的维护(申请、续期)一直是人工操作的。而每次ssl证书生命期的缩短，都是成倍的增加了项目的人工维护投入，也增加了人工出错导致事故、故障率；
acme的自动化，续费无需人工干预，在减少人工、降低故障率这一块具有天然优势。传统ssl接入acme对于自动化、降低人工成本、减少故障率都是有重大意义的。
25.如图1所示，本发明提供一种技术方案：一种传统ssl申请流程兼容acme的方法，该方法具体为以下步骤：
26.1、下单
27.启动acme.sh后，按照acme(rfc8555标准)流程进入下单步骤，将域名(可能有普通域名、通配符或者ip甚至ipv6地址)清单发送至acme的neworder接口，acme服务器的neworder接口收到域名后，创建订单数据，返回orderobjects。
28.2、提交csr
29.如果按照acme流程，下单后拿到orderobjects和authorizationobjects后，应该由客户端自动进行fqdn(域名或ip地址)验证的，但这里我们acme.sh客户端在1.下单成功后取得的订单详情中，获取authorizationobjects时候，我们对challenges中所有的token字段进行特殊处理。
30.type为dns-01的token返回格式如下：
31.dns-01#检查dns接口地址#http-01#./$(提交csr并返回dns解析的命令|bash-s)#
32.提交csr命令例如：
33.curl-s-f csr＝@$csr https：//acme-server/order/123/csr-dns？w＝\$_w
34.注意\$_w是acme.sh表示当前网站目录(http-01类型)或者使用的dnsapi模块名称。
35.type为http-01的token返回格式如下
36.随机字母#检查http接口地址#http-01#./$(提交csr并返回文件创建的命令|bash-s)#
37.提交csr命令例如：
38.curl-s-f csr＝@$csr https：//acme-server/order/123/csr-http？w＝\$_w
39.空格应用｀ifs＝^；cmd＝base64^-d；$cmd《《《ia＝＝`替代。
40.需要注意的是，ia＝＝为空格经过base64编码后的字符，之所以我们要用这个略微复杂的指令是因为acme.sh协议客户端在处理服务相应时候，其使用for循环，for循环会将服务返回的空格、逗号(半角)等符号识别成下一条命令等信号，所以我们需要避免在返回token中出现空格。ifs就可以满足需要：ifs是bash环境(linux+unix通用的bash脚本)下特殊分隔符的指令，比如普通的命令echo 123会输出123，我们用ifs＝^；cmd＝echo^123；$cmd即可达到同样的运行效果而命令执行过程不需要输入空格字符。这儿的作用就是输出一个空格。
41.：//应该用$(ifs＝^；cmd＝base64^-d；$cmd《＜《oi8v)替代(例如http：//和https：//结尾的：//)。
42.需要注意的是，oi8v是：//(也就是http：//或者https：//包含等字符)base64后字符，ifs作用同上，$(ifs＝^；cmd＝base64^-d；$cmd《》》oi8v)的作用就是替代：//的，避免acme.sh将：//当作特殊字符识别成下一条命令。
43.其中，提交csr步骤用其处理后的token以#字符分割第四段作为提交命令，并且
acme.sh会执行第四段之命令(是原生支持的，无需修改客户端来兼容此步骤)。
44.完成域名验证
45.执行完成“2.提交csr”之后，acme服务器应当返回域名的验证执行命令，因为我们使用了“|bash-s”管道，所以客户端在收到返回的命令后，会立即执行。
46.acme服务器返回的第一行应该为#！/bin/bash来避免客户端采用了zsh等与bash存在部分兼容性的终端导致的bug；
47.第2步提交csr的步骤应该返回：type为dns-01的token里面”提交csr”的url返回的内容需要有以下指令：
48.dns_《dns提供商》_add《dns主机名称》《dns解析值》
49.type为http-01的token里面”提交csr”的url返回的内容需要有以下指令：
50.mkdir-p
″
《目录》/.well-known/pki-validation
″
51.echo
″
《文件内容》
″
》
″
《目录》/.well-known/pki-validation/《文件名》.txt
52.其中，提交csr步骤用其处理后的token以#字符分割第四段作为提交命令，并且acme.sh会执行第四段之命令(是原生支持的，无需修改客户端来兼容此步骤)。
53.当acme.sh执行到token的#分割第四段时，就完成了csr的提交，这时候我们acme服务器就应该按照后续流程处理响应值，来达到自动解析dns验证或者自动上传http验证文件的目的，acme.sh协议客户端会执行token里面经过#分割后的第四段，所以我们将需要执行的命令(例如添加域名dns解析验证、创建验证文件)放在第四段，即可让acme.sh协议去执行，从而兼容非acme的ssl证书的申请流程，本方案就是利用acme.sh协议客户端会执行challenges中token被#分割后第四段指令的特性，直接绕过，让acme.sh先提交csr并完成ca要求的域名验证，由此解决acme对csr提交顺序以及域名验证的兼容问题的。
54.此处我们需要注意：
55.dns-01验证方式：因为acme.sh的dnsapi模块是写死了_acme-challenge主机头以及txt的解析类型，我们需要在服务器将客户端所用到的dnsapi(具体客户端采用了哪个dnsapi模块，我们可以通过“2.提交csr”客户端提交过来的$w参数获取)覆盖，将主机头改成传统的_《md5》或者_dnsauth，将解析类型改成cname或保持txt。返回的命令可以使用\$le_working_dir特殊变量用以定位到acme.sh的目录(例如加载acme.sh自带或dnsapi模块的文件)。
56.最后，再执行“dns_《dnsapi模块名称》_add《dns主机名称》《dns解析值》”(注意“dns_《dnsapi模块名称》_add”是无空格拼接起来的)即可实现域名的解析操作。
57.http-01验证方式：我们可以在“2.提交csr”返回输出文件的命令，到$_w下面的文件夹，例如echo
″
《http验证要求的文件内容》
″
》$w/.well-known/pki-validation/《文件名》.txt。
58.可能客户端运行的服务器上，暂时不存在$_w/.well-known/pki-validation文件夹，所以我们需要创建文件夹，例如mkdir-p$_w/.well-known/pki-validation。
59.签发
60.客户端调用acme的finalize接口去执行ca的检查域名验证接口实现证书的验证操作，此步骤完全和acme标准一样，不过acme服务器在此步骤必须忽略客户端发来的csr，因为在第2步，已经提交过了。
61.标准及业界依赖
62.acme的主流客户端是acme.sh，在其主要脚本中，在进行文件验证写入时，存在一个名为_exec函数的调用。我们可以想办法将我们的命令，拼接到_currentroot的值里面。
63.而_currentroot是将ventry按#切割后，使用第五部分，我们只需要让ventry第五部分包含我们想要执行的命令即可。而ventry是通过#符号拼接组成的：
64.域名#token#authorizationuri#challengetype#命令行webroot参数
65.我们可以让服务器返回的参数，通过添加“#”符号，从而实现acme.sh特殊变量的覆盖。这里我们就理通了我们实现利用acme.sh来自动化传统ca申请流程所需要的全部流程。
66.尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附实施例及其等同物限定。