CN114244516B - 多年期ssl证书申请时安全验证域名所有权的系统 - Google Patents
多年期ssl证书申请时安全验证域名所有权的系统 Download PDFInfo
- Publication number
- CN114244516B CN114244516B CN202111319131.2A CN202111319131A CN114244516B CN 114244516 B CN114244516 B CN 114244516B CN 202111319131 A CN202111319131 A CN 202111319131A CN 114244516 B CN114244516 B CN 114244516B
- Authority
- CN
- China
- Prior art keywords
- verification
- domain name
- module
- order
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
Abstract
本发明涉及一种多年期SSL证书申请时安全验证域名所有权的系统及方法,该系统包括:订单模块:用以接收申请者的证书请求,代理申请者向CA机构发送申请;邮件服务模块:用以向申请者提供用于接收验证邮件的指定唯一邮箱,并接收CA机构发送的验证邮件;自动验证模块:用以自动分析验证邮件服务模块接收到的验证邮件。与现有技术相比,本发明具有自动验证、操作简单、验证安全、保证跨账户验证的安全等优点。
Description
技术领域
本发明涉及数字证书安全验证技术领域,尤其是涉及一种多年期SSL证书申请时安全验证域名所有权的系统及方法。
背景技术
SSL证书作为一种常见的数字证书,由受信任的数字证书机构CA颁发,用于申请者浏览器与网站之间建立加密连接,以保护通讯网络中数据的安全性和私密性。如今各大主流浏览器的厂商对没有安装SSL证书的网站会提示“不安全或危险”,而安装了SSL证书的网站浏览器会显示安全标志,表示连接安全。
企业或个人网站站长在申请SSL证书时,按照行业规则,必须配合CA审查机构完成DCV(域控制验证)来证明对申请绑定的域名具有所有权,目前DCV主要有三种方式可供申请者选择:
(1)DNS验证方式
DNS验证方式又分为DNS TXT和DNS CNAME记录两种类型,不同的记录类型适用于不同的品牌证书,在证书申请时,CA机构会为申请域名生成的一个随机值,申请者需要将该随机值添加到DNS中作为TXT记录或CNAME记录中, CA机构会在线搜索该记录以确认随机值的存在。
(2)文件验证方式
当申请者没有DNS解析权限时,可使用文件验证方式。CA机构同样会为申请域名生成的一个随机值,申请者需要将该随机值写入域名根目录下指定位置的文件内(如,[domain]/.well-known/pki-validation/fileauth.txt),CA机构会在线审查该文件以确认该随机值。
(3)邮件验证方式
如果选择邮件验证,CA机构则会向申请者发送验证邮件。该邮件会发送到:
<i>域名WHOIS中列出的3个联系地址以及域名的5个常用系统邮箱地址共计8个固定地址,具体如下:
WHOIS联系地址:
域名注册人(Domain registrant);
技术联系人(Technical contact);
行政联系人(Administrative contact);
五个常用系统邮箱地址:
administrator@your_domain_name;
hostmaster@your_domain_name;
postmaster@your_domain_name;
webmaster@your_domain_name;
admin@your_domain_name;
<ii>申请者在DNS TXT值中设置的邮箱地址
该验证邮件包含一个带有验证令牌(Token)的链接,CA订单号或域名,申请者可以通过以下两种方式完成验证:
申请者只需打开并单击以上邮件中的任意一个验证链接,来确认对申请绑定的域名具有所有权
申请者将任意一个验证链接中的token,以及对应域名的ID,通过CA提供的RESTFul API的方式完成域名所有权的验证(需要编程实现,一般是由下游系统提提供的特制批准链接来实现,用户的体验和前面方式差别不大,但是验证过程的数据路径改变了)。
但是,对于以上三种验证方式,申请者需要大量的手动配置或操作,由于行业规则规定全球所有CA在2020年8月27号之后,无法再发出1年以上的有效期的证书,并且主流浏览器也不再信任1年期以上证书,所以对于多年期订单的申请者来说,申请的证书还需要每年重新申请,工作量大幅增加,操作起来相当繁琐,而且管理容易出错从而导致业务中断。
针对上述问题,目前有部分证书或服务器厂商提供了DNS验证或文件验证的自动化方式自动获取证书,以减轻证书申请者的操作管理负担,具体包括以下方式:
(1)DNS验证自动化
申请者在使用证书或服务器厂商的DNS服务时,厂商会自动为申请域名添加指定的DNS TXT或CNAME解析,以配合CA中心的在线审查,实现DNS验证的自动化,但是该方式有一定的场景限制,例如必须使用腾讯云的DNS服务,并在腾讯云上购买SSL证书。
(2)文件验证自动化
申请者只需在服务器上启动一个Web服务并监听80或443端口,将文件验证路径地址反向代理为证书或服务器厂商提供的反向代理地址,以配合CA中心的在线审查,实现文件验证的自动化,但是该方式对线上服务有一定的侵入性,并且安全系数不高,新的行业规范也将降低此方式能签发SSL证书的等级。
相较于DNS验证和文件验证,不需要一定的建站基础,安全系数更高邮件验证至今还没有被任何厂商将其安全便捷的自动化实现,据CA/B论坛发出的通知,从2021年12月1日起,通配符SSL证书将不支持文件验证域名,此次域名验证方式的重大变更将直接导致更多的证书申请者选择邮件验证这种方式,将邮件验证自动化也将成为未来的一种新需求。
而现有的邮件模式是用户经过订单系统(代理商)到CA机构申请SSL证书, CA机构是直接发送挑战码(验证值)到用户去配置并进行响应,完成手动DCV 验证,订单系统并不影响DCV验证过程的安全性,如果采用集中的自动化DCV 验证,将响应挑战的权利进行了转移,便利性大大提升了,但是衍生了以下安全问题:
(1)如何证明“你是你”的问题,避免未经授权的用户到其他CA机构为你的域名申请SSL证书。当你为域名配置好一个“永久”的验证邮箱进行自动响应 CA机构的挑战,如果其他人到任何一家CA机构为相同域名进行申请SSL证书,也将自动完成DCV验证和SSL证书签发,对于CA机构侧是无法感知到是否是你本人发起的申请。
(2)对于一个订单系统内,多租户环境下,系统如何区分是哪个用户向哪个 CA机构发起了SSL证书申请,同时当CA机构过来验证时,如何确保不同CA机构到用户的不同批次SSL证书申请的DCV验证是隔离的、安全并经过授权的。
发明内容
本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种多年期SSL 证书申请时安全验证域名所有权的系统及方法。
本发明的目的可以通过以下技术方案来实现:
一种多年期SSL证书申请时安全验证域名所有权的系统,该系统包括:
订单模块:用以接收申请者的证书请求,代理申请者向CA机构发送申请;
邮件服务模块:用以向申请者提供用于接收验证邮件的指定唯一邮箱,并接收 CA机构发送的验证邮件;
自动验证模块:用以自动分析验证邮件服务模块接收到的验证邮件。
一种多年期SSL证书申请时安全验证域名所有权的验证方法,包括以下步骤:
1)申请者向订单模块发起证书请求;
2)订单模块产生订单并从邮件服务模块获取用于接收验证邮件的指定唯一邮箱;
3)申请者将指定唯一邮箱设置为用于直接接收验证邮件的邮箱,或者用以接收从固定邮箱转发的验证邮件的目的邮箱;
4)订单模块向CA机构发送证书请求,CA机构在接收到订单模块的证书请求后向指定唯一邮箱直接发送验证邮件,或者通过固定邮箱转发到指定唯一邮箱;
5)邮件服务模块接收验证邮件并通知自动验证模块;
6)自动验证模块对验证邮件进行自动分析和安全校验;
7)在安全校验通过后,CA机构判断验证通过后向该申请者颁发SSL证书。
所述的步骤1)具体为:
申请者向订单模块提交【待验证域名1】并选择DCV方式为邮件验证,发起证书请求。
所述的步骤2)具体为:
订单模块产生与【待验证域名1】关联的【订单号1】并从邮件服务模块处获取指定唯一邮箱地址返回给申请者,通过对【订单号1】+【随机值】进行加密得到【密文唯一值】的方式产生唯一邮箱地址,则指定唯一邮箱地址的格式具体为:
【密文唯一值】@代理验证域名。
所述的步骤3)中,申请者将用以接收验证邮件的邮箱通过DNS TXT记录设置为指定唯一邮箱,并在设置完成后通知订单模块,所述的DNS TXT记录内容具体为:
所述的步骤3)中,申请者将用于接收验证邮件的8个固定邮箱中的任意一个设置自动转发,将来自CA机构的验证邮件转发到指定唯一邮箱,并在设置完成后通知订单模块,所述的用于接收验证邮件的8个固定邮箱地址包括WHOIS中的3 个联系地址和5个常用系统邮箱地址。
所述的步骤3)中,订单模块在收到指定唯一邮箱的设置完成通知后正式向 CA机构提交订单申请,获取【CA订单号1】或【域名ID】,并与【订单号1】关联存储。
所述的步骤6)中,自动验证模块读取验证邮件,进行分析自动分析和安全校验,具体包括以下步骤:
601)对验证邮件的【To邮件地址】的密文唯一值进行解密提取到【订单号2】;
602)从验证邮件内容中提取【CA订单号2】和【批准URL】;
603)通过【CA订单号2】从订单模块获取【订单号1】;
604)如果由于【CA订单号1】与【CA订单号2】不相同,导致从订单模块中无法获取到【订单号1】,或者获取的【订单号1】与提取到的【订单号2】不匹配,则安全验证不通过,终止流程,反之,则安全验证通过,自动验证模块通过爬虫技术自动点击【批准URL】。
所述的步骤6)中,自动验证模块读取验证邮件,进行分析自动分析和安全校验,具体包括以下步骤:
611)对验证邮件的【To邮件地址】的密文唯一值进行解密提取到【订单号2】;
612)从邮件内容中提取批准URL中的Token和【待验证域名2】;
613)通过【订单号2】从订单模块获取【待验证域名1】和【域名ID】;
614)比较【待验证域名1】和【待验证域名2】是否相同,若不相同则安全验证不通过,终止流程,若相同,则安全验证通过,自动通过CA机构的RESTful API 发送【域名ID】和Token触发DCV请求。
当多年期SSL证书申请时安全验证域名所有权的第2年-第n年进行验证时:
当证书进入30天续费期内时,订单模块自动向CA机构提交续期订单,即重新申请证书,并重复步骤4~7)完成当年的证书自动签发。
与现有技术相比,本发明具有以下优点:
1、申请者仅需将用于接收验证邮件的邮箱地址设置为订单模块指定的唯一邮箱,后续无须任何操作即可完成多年期SSL证书申请和域名所有权审核进而实现 SSL证书自动化续期和批量部署。
2、申请者无需从WHOIS中列出的3个联系邮箱以及域名的5个常用系统邮箱这8个固定邮箱的访问权限,仅需在DNS处设置TXT记录值即可。
3、相较于DNS验证的自动化,如果用户因为安全等限制没有DNS配置权限,还可以选择在WHOIS中列出的其中一个邮箱内配置邮件转发即可。
4、相较于文件验证的自动化,邮件验证自动化的安全系数更高,可以签发通配符SSL证书,申请者无需服务器操作权限,只需按照提示将用于接收DCV邮件的邮箱设置为订单模块指定的唯一邮箱。
5、通过配置的指定唯一邮箱地址(例如加密(【订单号】+【随机值】)@dcv.httpsauto.com),用于解决跨多租户场景下跨账户验证的安全问题,可防止其他人通过已经配置好的邮件自动验证通道完成DCV验证进行SSL证书签发,主要是利用订单号、CA订单、域名ID在各独立系统内的唯一性,通过订单号下关联的几个过程的存储与传递来实现安全校验。
附图说明
图1为本发明的整体工作流程图。
图2为本发明实施例1中安全验证的方法流程图。
图3为本发明实施例2中安全验证的方法流程图。
图4为本发明实施例3中安全验证的方法流程图。
图5为本发明实施例4中安全验证的方法流程图。
具体实施方式
下面结合附图和具体实施例对本发明进行详细说明。
本发明提供一种多年期SSL证书申请时安全验证域名所有权的系统及方法,用于解决现有域名所有权验证方式中邮件验证没有实现自动化的问题,以提高多年期SSL证书申请和审核的效率,安全地重新获取到证书,以减轻操作和管理负担,满足SSL证书申请、续期的自动化。
该验证域名所有权的系统包括订单模块、邮件服务模块和自动验证模块,订单模块用于接收申请者证书请求,代理申请者向CA机构发送申请,邮件服务模块向申请者提供用于接收验证邮件的指定唯一邮箱,并接收CA机构发送的验证邮件,自动验证模块自动分析验证邮件服务模块接收到的DCV邮件。
基于上述系统,该验证域名所有权的方法包括以下步骤:
1、申请者向订单模块发起证书申请。
2、订单模块产生订单并向邮件服务模块获取指定唯一邮箱。
3、申请者将用于接收DCV邮件的邮箱设置为该指定唯一邮箱(本发明提供两种方法,直接设置和转发)。
4、CA机构接收到上述订单模块的请求后向该指定唯一邮箱发送DCV邮件。
5、邮件服务模块接收该DCV邮件并通知自动验证模块。
6、自动验证模块自动分析、安全校验、验证DCV邮件。
7、CA机构判断验证通过后向该申请者颁发SSL证书。
实施例1
本例中给出第一种验证方法,如图2所示,具体包括以下步骤:
1、申请者向订单模块提交【待验证域名1】并选择DCV方式为邮件验证,发起证书申请;
2、订单模块存储【待验证域名1】并产生与其关联的【订单号1】并从邮件服务模块处获取指定唯一邮箱地址返回给该申请者,本例中采用对【订单号1】+【随机值】进行加密得到【密文唯一值】的方式产生指定唯一邮箱地址,其格式具体为:
密文唯一值@dcv.httpsauto.com(代理验证域名);
3、该申请者将用于接收验证邮件的邮箱通过DNS TXT记录设置为上述指定唯一邮箱,设置完成后通知上述订单模块,如图1中“下订单”的A步所示,DNS TXT记录如表1所示,则有:
表1 DNS TXT记录
4、该订单模块收到通知后正式向CA机构提交订单申请,获得【CA订单号 1】,与【订单号1】关联存储;
5、CA机构接收到该订单申请后检测DNS TXT记录,并向检测到的指定唯一邮箱发送验证邮件;
6、邮件服务模块接收到验证邮件并通知自动验证模块;
7、自动验证模块读取验证邮件进行分析:
a)从验证邮件的【To邮件地址】(密文唯一值@dcv.httpsauto.com)中解密提取到【订单号2】;
b)从验证邮件内容中提取【CA订单号2】和【批准URL】;
8、该自动验证模块进行安全校验;
a)通过【CA订单号2】从订单模块获取【订单号1】;
b)如果由于【CA订单号1】与【CA订单号2】不相同导致无法从订单模块获取【订单号1】,或者获取的【订单号1】与提取的【订单号2】不匹配,则安全验证不通过,终止流程;
通过邮件地址和邮件内容中的关键信息,完成本系统->CA机构->用户的安全闭环校验(系统订单【订单号1】->CA订单【CA订单号1】->CA验证邮件【订单号2&CA订单号2】->用户配置授权【xxx@dcv.httpsauto.com】->系统订单匹配【订单号1】=【订单号2】),有效防止其他用户,多租户环境下的安全绕过问题。
9、如果安全验证通过,自动验证模块通过爬虫技术自动点击【批准URL】;
10、CA机构判断验证通过后向该申请者颁发SSL证书。
对于多年期第2年-第n年时:
当证书进入30天续费期,订单模块自动向CA机构提交续期订单(重新申请证书),并重复4~10步骤完成第二年证书自动签发(包括自动DCV验证)。
实施例2
本例中给出第二种验证方法,如图3所示,具体包括以下步骤:
1、申请者向订单模块提交【待验证域名1】并选择DCV方式为邮件验证,发起证书申请;
2、订单模块存储【待验证域名1】并产生与其关联的【订单号1】并从邮件服务模块处获取指定唯一邮箱地址返回给该申请者,本例中采用对【订单号1】+【随机值】进行加密得到【密文唯一值】的方式产生指定唯一邮箱地址,其格式具体为:
密文唯一值@dcv.httpsauto.com(代理验证域名);
3、申请者将用于接收DCV邮件的邮箱通过DNS TXT记录设置为上述指定唯一邮箱,设置完成后通知上述订单模块,如图1中“下订单”的A步所示,DNS TXT 记录如表2所示,则有:
表2 DNS TXT记录
4、订单模块接到通知后正式向CA机构提交订单申请,获得【域名ID】,与【订单号1】关联存储;
5、CA机构接收到该订单申请后检测DNS TXT记录,并向检测到的指定唯一邮箱发送验证邮件;
6、邮件服务模块接收到验证邮件并通知自动验证模块;
7、自动验证模块读取验证邮件进行分析:
a)从验证邮件的【To邮件地址】(密文唯一值@dcv.httpsauto.com)中解密提取到【订单号2】;
b)从邮件内容中提取批准URL中的Token和【待验证域名2】;
8、自动验证模块进行安全校验:
a)通过【订单号2】从订单模块获取【待验证域名1】和【域名ID】;
b)比较【待验证域名1】和【待验证域名2】是否相同,若不相同则安全验证不通过,终止流程;
9、若相同,则安全验证通过,自动通过CA机构的RESTful API发送【域名 ID】和Token触发DCV请求;
10、CA机构判断验证通过后向该申请者颁发SSL证书。
对于多年期第2年-第n年时:
当证书进入30天续费期,订单模块自动向CA机构提交续期订单,并重复4~10 步骤完成第二年证书自动签发(包括自动DCV验证)。
实施例3
本例中给出第三种验证方法,如图4所示,具体包括以下步骤:
1、申请者向订单模块提交【待验证域名1】并选择DCV方式为邮件验证,发起证书申请;
2、订单模块存储【待验证域名1】并产生与其关联的【订单号1】并从邮件服务模块处获取指定唯一邮箱地址返回给该申请者,本例中采用对【订单号1】+【随机值】进行加密得到【密文唯一值】的方式产生指定唯一邮箱地址,其格式具体为:
密文唯一值@dcv.httpsauto.com(代理验证域名);
3、申请者将用于接收DCV邮件的8个邮箱中的任意一个设置自动转发,通过在邮箱收件规则下新建规则,将来自CA机构的验证邮件(如 no-reply@digitalcertvalidation.com)转发到上述指定唯一邮箱中,设置完成后通知订单模块,如图1中“下订单”的B步所示;
4、订单模块收到通知后正式向CA机构提交订单申请,获得【CA订单号2】,并与【订单号1】关联存储;
5、CA机构接收到该订单申请后向用于接收DCV邮件的8个邮箱发送验证邮件,验证邮件通过自动转发功能转发到指定唯一邮箱;
6、邮件服务模块接收到验证邮件并通知自动验证模块;
7、自动验证模块读取验证邮件进行分析:
a)从验证邮件的【To邮件地址】(密文唯一值@dcv.httpsauto.com)中解密并提取【订单号2】;
b)从验证邮件内容中提取【CA订单号2】和【批准URL】;
8、自动验证模块进行安全校验:
a)通过【CA订单号2】从订单模块获取【订单号1】;
b)如果获取不到,或者获取的【订单号1】与提取的【订单号2】不匹配,则安全验证不通过,终止流程;
9、如果安全验证通过,自动验证模块通过爬虫技术自动点击【批准URL】;
10.CA机构判断验证通过后向该申请者颁发SSL证书。
对于多年期第2年-第n年时:
当证书进入30天续费期,订单模块自动向CA机构提交续期订单,并重复4~10 步骤完成第二年证书自动签发(包括自动DCV验证)。
实施例4
本例中给出第四种验证方法,如图5所示,具体包括以下步骤:
1、申请者向订单模块提交【待验证域名1】并选择DCV方式为邮件验证,发起证书申请;
2、订单模块存储【待验证域名1】并产生与其关联的【订单号1】并从邮件服务模块处获取指定唯一邮箱地址返回给该申请者,本例中采用对【订单号1】+【随机值】进行加密得到【密文唯一值】的方式产生指定唯一邮箱地址,其格式具体为:
密文唯一值@dcv.httpsauto.com(代理验证域名);
3、申请者将用于接收DCV邮件的8个邮箱中的任意一个设置自动转发,通过在邮箱收件规则下新建规则,将来自CA机构的验证邮件(如 no-reply@digitalcertvalidation.com)转发到上述指定唯一邮箱中,设置完成后通知订单模块,如图1中“下订单”的B步所示;
4、该订单模块收到通知后正式向CA机构提交订单申请,获得【域名ID】,与【订单号1】关联存储;
5、CA机构接收到该订单申请后向用于接收DCV邮件的8个邮箱发送验证邮件,验证邮件通过自动转发功能转发到指定的唯一邮箱;
6、邮件服务模块接收到该验证邮件并通知自动验证模块;
7、自动验证模块读取验证邮件进行分析:
a)从验证邮件的【To邮件地址】(密文唯一值@dcv.httpsauto.com)中解密提取到【订单号2】;
b)从邮件内容中提取批准URL中的Token和【待验证域名2】;
8、自动验证模块进行安全校验:
a)通过【订单号2】从订单模块获取【待验证域名1】和【域名ID】;
b)比较【待验证域名1】和【待验证域名2】是否相同,若不相同则安全验证不通过,终止流程;
9、若相同,则安全验证通过,自动通过CA机构的RESTful API发送【域名 ID】和Token触发DCV请求;
10.CA机构判断验证通过后向该申请者颁发SSL证书;
对于多年期第2年-第n年时:
当证书进入30天续费期,订单模块自动向CA机构提交续期订单,并重复4~10 步骤完成第二年证书自动签发(包括自动DCV验证)。
Claims (6)
1.一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,该系统包括:
订单模块:用以接收申请者的证书请求,代理申请者向CA机构发送申请;所述CA机构为证书授证中心;
邮件服务模块:用以向申请者提供用于接收验证邮件的指定唯一邮箱,并接收CA机构发送的验证邮件;
自动验证模块:用以自动分析验证邮件服务模块接收到的验证邮件;
所述多年期SSL证书申请时安全验证域名所有权的系统的验证方法,包括以下步骤:
1)申请者向订单模块发起证书请求;
2)订单模块产生订单并从邮件服务模块获取用于接收验证邮件的指定唯一邮箱;
订单模块产生与待验证域名1关联的订单号1并从邮件服务模块处获取指定唯一邮箱地址返回给申请者,通过对订单号1+随机值进行加密得到密文唯一值的方式产生唯一邮箱地址,则指定唯一邮箱地址的格式具体为:
密文唯一值@代理验证域名;
3)申请者将指定唯一邮箱设置为用于直接接收验证邮件的邮箱,或者用以接收从固定邮箱转发的验证邮件的目的邮箱;
申请者将用以接收验证邮件的邮箱通过DNS TXT记录设置为指定唯一邮箱,并在设置完成后通知订单模块,所述的DNS TXT记录内容具体为:
解析类型:TXT;
记录名:_validation-contactemail;
记录值:密文唯一值@代理验证域名;
TTL:Auto;
或,
申请者将用于接收验证邮件的8个固定邮箱中的任意一个设置自动转发,将来自CA机构的验证邮件转发到指定唯一邮箱,并在设置完成后通知订单模块,所述的用于接收验证邮件的8个固定邮箱地址包括WHOIS中的3个联系地址和5个常用系统邮箱地址;
4)订单模块向CA机构发送证书请求,CA机构在接收到订单模块的证书请求后向指定唯一邮箱直接发送验证邮件,或者通过固定邮箱转发到指定唯一邮箱;
5)邮件服务模块接收验证邮件并通知自动验证模块;
6)自动验证模块对验证邮件进行自动分析和安全校验;
7)在安全校验通过后,CA机构判断验证通过后向该申请者颁发SSL证书。
2.根据权利要求1所述的一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,所述的步骤1)具体为:
申请者向订单模块提交待验证域名1并选择DCV方式为邮件验证,发起证书请求,所述DCV方式为域名所有权验证。
3.根据权利要求1所述的一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,所述的步骤3)中,订单模块在收到指定唯一邮箱的设置完成通知后正式向CA机构提交订单申请,获取CA订单号1或域名ID,并与订单号1关联存储。
4.根据权利要求3所述的一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,所述的步骤6)中,自动验证模块读取验证邮件,进行分析自动分析和安全校验,具体包括以下步骤:
601)对验证邮件的To邮件地址的密文唯一值进行解密提取到订单号2,所述To邮件地址为收件人邮件地址;
602)从验证邮件内容中提取CA订单号2和批准URL;
603)通过CA订单号2从订单模块获取订单号1;
604)如果由于CA订单号1与CA订单号2不相同,导致从订单模块中无法获取到订单号1,或者获取的订单号1与提取到的订单号2不匹配,则安全验证不通过,终止流程,反之,则安全验证通过,自动验证模块通过爬虫技术自动点击批准URL。
5.根据权利要求3所述的一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,所述的步骤6)中,自动验证模块读取验证邮件,进行分析自动分析和安全校验,具体包括以下步骤:
611)对验证邮件的To邮件地址的密文唯一值进行解密提取到订单号2;
612)从邮件内容中提取批准URL中的Token和待验证域名2;
613)通过订单号2从订单模块获取待验证域名1和域名ID;
614)比较待验证域名1和待验证域名2是否相同,若不相同则安全验证不通过,终止流程,若相同,则安全验证通过,自动通过CA机构的RESTfulAPI发送域名ID和Token触发DCV请求。
6.根据权利要求1所述的一种多年期SSL证书申请时安全验证域名所有权的系统,其特征在于,当多年期SSL证书申请时安全验证域名所有权的第2年-第n年进行验证时:
当证书进入30天续费期内时,订单模块自动向CA机构提交续期订单,即重新申请证书,并重复步骤4~7)完成当年的证书自动签发。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111319131.2A CN114244516B (zh) | 2021-11-09 | 2021-11-09 | 多年期ssl证书申请时安全验证域名所有权的系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111319131.2A CN114244516B (zh) | 2021-11-09 | 2021-11-09 | 多年期ssl证书申请时安全验证域名所有权的系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114244516A CN114244516A (zh) | 2022-03-25 |
CN114244516B true CN114244516B (zh) | 2023-02-24 |
Family
ID=80748738
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111319131.2A Active CN114244516B (zh) | 2021-11-09 | 2021-11-09 | 多年期ssl证书申请时安全验证域名所有权的系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114244516B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116684382B (zh) * | 2023-07-28 | 2023-10-20 | 深圳市豪斯莱科技有限公司 | 域名检测、自动化申请域名证书方法、系统和存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103944719A (zh) * | 2014-04-02 | 2014-07-23 | 尚清实业(上海)有限公司 | 一种身份和证明文件的综合验证系统及方法 |
JP2021016149A (ja) * | 2020-06-08 | 2021-02-12 | 一般財団法人日本情報経済社会推進協会 | 電子証明書導入・運用システム、電子証明書導入・運用方法、及び証明書申請装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2002335062B2 (en) * | 2001-10-12 | 2007-07-19 | Digicert, Inc. | Methods and systems for automated authentication, processing and issuance of digital certificates |
US8103761B2 (en) * | 2004-06-25 | 2012-01-24 | Go Daddy Holding Company, LLC | Methods of issuing a credit for a certificate for a domain name |
US20110055562A1 (en) * | 2009-08-28 | 2011-03-03 | The Go Daddy Group, Inc. | Public key certificate based social website account authentication |
-
2021
- 2021-11-09 CN CN202111319131.2A patent/CN114244516B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103944719A (zh) * | 2014-04-02 | 2014-07-23 | 尚清实业(上海)有限公司 | 一种身份和证明文件的综合验证系统及方法 |
JP2021016149A (ja) * | 2020-06-08 | 2021-02-12 | 一般財団法人日本情報経済社会推進協会 | 電子証明書導入・運用システム、電子証明書導入・運用方法、及び証明書申請装置 |
Non-Patent Citations (2)
Title |
---|
Cloud Strife:减轻域验证证书的安全风险;郭润;《中国教育网络》;20180605(第06期);41-43 * |
Domain Impersonation is Feasible:A Study of CA Domain Validation Vulnerabilities;Lorenz Schwittmann 等;《2019 IEEE European Symposium on Security and Privacy (EuroS&P)》;IEEE;20190822;第547-551页 * |
Also Published As
Publication number | Publication date |
---|---|
CN114244516A (zh) | 2022-03-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9871791B2 (en) | Multi factor user authentication on multiple devices | |
CN108684041B (zh) | 登录认证的系统和方法 | |
US8812838B2 (en) | Configuring a valid duration period for a digital certificate | |
US10567370B2 (en) | Certificate authority | |
US8499339B2 (en) | Authenticating and communicating verifiable authorization between disparate network domains | |
US8078870B2 (en) | HTTP-based authentication | |
US8532620B2 (en) | Trusted mobile device based security | |
CA2578186C (en) | System and method for access control | |
US20050021975A1 (en) | Proxy based adaptive two factor authentication having automated enrollment | |
US9530013B2 (en) | Supporting the use of a secret key | |
CN103237305B (zh) | 面向移动终端上的智能卡密码保护方法 | |
JP2015528149A (ja) | 企業トリガ式2chk関連付けの起動 | |
JP2015519777A (ja) | マルチパーティシステムにおける安全な認証 | |
JP2006525563A (ja) | ユーザとウェッブ・サイトの認証方法及び装置 | |
JP2015526784A (ja) | 問い合わせ型トランザクションによる強化された2chk認証セキュリティ | |
JP2009514050A (ja) | クライアント−サーバ環境においてクライアントを認証するためのシステムおよび方法 | |
EP2404427B1 (en) | Method and apparatus for securing network communications | |
EP2957064B1 (en) | Method of privacy-preserving proof of reliability between three communicating parties | |
US11165768B2 (en) | Technique for connecting to a service | |
CN107864475A (zh) | 基于Portal+动态密码的WiFi快捷认证方法 | |
JP2001186122A (ja) | 認証システム及び認証方法 | |
CN114244516B (zh) | 多年期ssl证书申请时安全验证域名所有权的系统 | |
KR100750214B1 (ko) | 공인 인증서를 이용한 로그인 방법 | |
JP2017152877A (ja) | 電子鍵再登録システム、電子鍵再登録方法およびプログラム | |
KR20150083178A (ko) | 인증서 관리 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |