信创SM2根证书计划360 Browser Root Certificate Program
信创SM2根证书计划
随着我国《密码法》2020年1月1日正式实施,应网络安全形式、国家网络战略及密码领域法律建设所需,建立国产自主商用密码体系迫在眉睫。
数字证书作为互联网用户访问的安全基石至关重要,各大操作系统或浏览器都有自己的根证书计划。360浏览器于2018年12月正式启动根证书计划(https://caprogram.360.cn/),接受国内外的CA厂商的入根申请,目前已经接纳18个CA厂商,63个根的申请,已经成长为中国唯一、世界第五大的根证书库,但预置的都是RSA或者ECC的根。
目前,360根证书计划依赖于国际组织CA/Browser Forum制定的基线要求和WebTrust或ETSI审计,因此也只覆盖了RSA和ECC证书,SM2证书并未囊括。我国对商用密码CA机构和SM2根证书的管理以资质许可方式进行(如电子认证服务使用密码许可证、电子认证服务许可证,电子政务电子认证服务许可),并未仿照CA/Browser Forum的模式。国际审计组织对SM2证书的审计不是必选项。
浏览器对信创SM2数字证书的支持是商用密码推广的重要基础,其中SM2根证书的管理又最为关键,360综合以上因素实验性的接纳SM2根证书入根申请,试运行期间优先在360安全浏览器(信创版)和战略合作伙伴(麒麟软件、统信软件、中科方德)的操作系统中进行预置。
在系统证书体系建设中,360将采用WebTrust国际标准为战略合作伙伴建设CA系统,并遵循国家国密标准,支持为用户签发SM2证书,按照国际标准生成顶级根密钥和中级根证书,并按照国际标准管理证书生命周期,包括证书申请、证书签发、证书使用、证书吊销、证书续期等管理。
360浏览器将与战略合作伙伴共同发起国密根证书计划,共建共享信创SM2国密根证书库。双方将符合国密标准,加入国密根证书计划的CA厂商,认定为受到操作系统信任的数字证书发布机构,将发布机构的数字证书默认安装到操作系统中。从而使得在国密根证书计划中的CA厂商所发布的数字证书,直接获得操作系统和浏览器的联合认证。360与战略合作伙伴共同发起和维护国密根证书库,将有助于国密数字证书生态的健康发展,更将通过联合CA厂商,推动CA认证技术改造,增强对证书问题的应对能力,保障信创安全。
360作为信创SM2国密根证书计划的发起人、技术支撑人和管理者,360有权移除任何证书。
信创SM2根证书计划主要适用于360安全浏览器和战略合作伙伴的操作系统。
浏览器相关问题:pc_browser_kefu@360.cn
CA厂商申请入根:caprogram@360.cn
信创SM2根证书认证策略
1.0版本
  1. 1.介绍
  2. 当发布360相关软件产品的二进制和源代码时,360使用这样的软件包括一组针对各种认证机构(CA)的符合国家密码管理局要求的SM2算法根证书。所包含的证书具有为各种目的设置的“信任位”,使得所述软件可以使用CA证书来锚定SSL服务器证书的信任链,而不用要求用户进一步许可或信息。
    360官方负责人将维护这一策略并评估来自CA的新请求,360有权随时修改该策略。
    360将决定哪些CA证书可以加入信创SM2根证书计划,独立加入系统根信任库,因此,360也有权决定在根证书计划中移除某个CA证书。
    CA厂商的SM2根证书申请加入信创SM2浏览器根证书计划时,360不会收取任何费用。
  3. 2.主体单位资质
  4. 所有CA机构必须:
    1. 1.申请SM2根证书预埋的CA机构必须获得国家密码主管机构和电子认证服务主管机构办法的相关许可资质,须持有以下资质:
    2. · 电子认证服务使用密码许可证(国家密码管理局)
      · 电子认证服务许可证(工信部)
    3. 2.CA机构需证明使用的商用密码的软件、硬件需获得依法设立的商用密码认证机构颁发的认证证书。
    4. 3.CA机构提供的以上资质文件应该在有效期内,如相关资质文件已超出有效期,且在向主管机构申请更新续期的过程中,需提供补充的证明资料。
  5. 3.技术要求
  6. 所有CA机构必须:
    证书类别:
    1. 1.申请预埋的SM2根证书只接受合规主体单位签发的商业运行需要的SM2证书。
    2. 2.国家电子认证根CA的社会公众应用根证书(SM2)和公务人员应用根证书(SM2)会默认预制,主要且用于验证用户使用USB Key证书做双向认证。
    审计要求(任选其一):
    1. 1.有WebTrust审计报告,提供审计报告的链接。
    2. 2.没有WebTrust审计报告,且根证书生成早于2020年7月1日的,提供录像证明安全生成中级证书的过程。
    3. 3.没有WebTrust审计报告,且根证书生成晚于2020年7月1日的,提供录像证明安全生成根证书,中级证书的过程。
    安全证书生产要求:
    1. 1.给出全程录像,按照时间线标注以下基本重要信息。
    2. · 场地:密钥生成过程应该实施在符合国密和工信要求的场地安全区内实施。
      · 人员:操作人员必须是本单位员工,至少2人同时在场。
      · 过程:根密钥生成仪式应该有设计好的脚本,并经过审批,全程应有内部审计人员在场,并记录。 实施过程,所有与设计脚本偏差内容应进行记录说明,根密钥生成过程应全程录像。
    技术基线要求:
    1. 1.CA机构的根证书的最长有效期不能超过25年;从提交申请开始计算,根证书的剩余有效期至少超过8年。
    2. 2.根证书必须符合国家密码主管机构SM2密码算法使用规范,要求使用256Bit。
    3. 3.CA机构必须维护一个7*24可用的在线信息库;公开发布可访问的证书策略CP和证书业务规则CPS。
    4. 4.CP和CPS的框架必须遵照《电子认证业务规则规范》要求。
    5. 5.CA机构必须在CP/CPS中清晰列出根证书体系,包含申请根证书签发的内部和外部的子CA。
    6. 6.CA机构必须形成事件报告机制,在发生如根证书私钥泄露、基础设施故障、签发错误的用户证书等严重事件时,CA应在事故发现24小时之内通知360公司与战略合作伙伴(麒麟软件、统信软件、中科方德),并在48小时之内向360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)提供完整的事件报告。
    7. 7.CA机构需要在CP/CPS及官网提供面向订户和依赖方的证书问题报告通道。
    8. 8.CA机构的CP/CPS每年至少更新一次,且在CP/CPS里需要列出清晰的版本号,变更的主要内容和生效时间。
    9. 9.CA机构签发的证书必须符合GB/T 20518-2018 《信息安全技术 公钥基础设施数字证书格式》。
    10. 10.CA机构不允许向Local Name(本地主机名)和私有IP地址颁发证书,对私有IP段的维护,可直接引用IANA数据库。
    11. 11.CA机构必须提供有效的证书吊销列表CRL和证书状态查询服务OCSP,CRL需要符合RFC5280标准,OCSP需符合RFC6960和/或 5019标准,CT需符合RFC6962标准,以上标准关于算法的要求采用SM2/3/4进行替换。
    12. 12.CA机构必须提交商用密码证书的CTLog到360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)认可的CT服务器上(具体要求需等待本计划的SM2 CT服务器建立完毕后执行)。
    13. 13.CA机构的CP或CPS中必须明确的列出对于证书申请人,申请域名或IP地址的鉴证方法和过程。
    14. 14.CA机构必须就每一个申请的根证书搭建维护3个测试网站,并分别部署有效的,过期的,吊销的3类证书以供360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)进行检查核验。
    15. 15.订户证书的有效期最大不能超过398天;
    16. 16.根ARL的最长有效期为12个月,每12个月更新一次;订户CRL的有效期最长为10天,最少每7天更新一次;当发生子CA证书被吊销的情况,根ARL需要在24小时之内更新;
    17. 17.OCSP对订户证书响应的最长有效期为7天,最少每4天更新一次;OCSP对子CA证书响应的最长有效期为12个月,每12个月更新一次;当出现子CA证书被吊销的情况,OCSP响应需要在24小时之内更新。
    18. 18.CA机构的根证书及子CA证书必须在获得国家密码管理主管机构颁发产品国推商用密码认证的HSM硬件安全模块中产生。(符合 GB/T 37092-2018 信息安全技术 密码模块安全要求)。
    19. 19.CA机构不允许生成并向订户发送私钥。
  7. 其他说明
    1. 1.360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)将会根据国家密码主管机构和电子认证服务主管机构的政策变化,进行相应的根预置策略调整;
    2. 2.360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)拥有该根预置策略的最终解释权,当360与战略合作伙伴(麒麟软件、统信软件、中科方德)认为有必要时,CA机构需要配合提供更多资料来证明CA机构在运营规范和安全防护方面采取的措施符合360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)预置的要求。
    3. 3.当360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)认为特定根证书对于互联网生态及360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)用户存在潜在的风险和危害时,360公司与战略合作伙伴(麒麟软件、统信软件、中科方德)有权利拒绝该根证书的预置,或从已完成预埋的信任列表中剔除该根证书。
信创SM2根证书认证流程
信创SM2根证书认证过程,包括CA申请、信息验证、批准请求、预置测试、正式信任五个部分。
为完成根证书预置,CA机构必须遵守信创SM2根证书认证策略的规定,并提供所有需要的材料,360浏览器根认证项目负责人将会对这些材料进行审核。
一. CA申请
  1. 申请加入的组织必须是一个合法的证书颁发机构(CA)。
  2. 根证书预置申请必须以公司名义提出,CA机构的官方代表必须参与到根证书预置的申请工作中,且有能力与360项目负责人沟通处理任何问题。
  3. CA代表将会向360发送一封邮件,内含所有必要的申请信息,以提交正式请求。
  4. CA必须填写信创SM2国密根证书预置申请表,包括CA机构的基本信息、根证书的技术参数、根证书的层级信息、策略几个部分内容。
  5. CA确保提交的所有文件、审计报告,符合国家密码管理局和工信部的相关规定。
二. 信息验证
  1. 360将指定官方负责人处理CA信息审核。如果有需要,360会要求提供额外的信息。这个过程一般在一个月内完成,具体持续时间取决于CA提供的信息的完整性和CA对问题的反应时间。
  2. 检查CA提供的SM2根证书文件是否符合CA/BR要求,相关的CRL、AIA、OCSP服务是否正常运行。
  3. 检查CP/CPS内容是否符合BR对CA机构的要求,确保CP/CPS跟进BR的最新版本,定期进行更新,并保证CP/CPS能随时在线浏览。
  4. 检查CA提供的审计报告是否满足信创SM2根认证策略中对于审计的要求。
  5. 在这一阶段,对于CA提交的材料有不清楚或有疑问的地方,360可能会要求提供额外的信息或做进一步澄清。
三. 批准请求
  1. 若CA机构的业务操作、管理等情况得到360的普遍认可,360将把CA根预置请求进入批准阶段。
  2. 对于CA机构的根预置请求,信创SM2根证书计划项目负责人具有最终决定权。
    1. 若请求未批准,360将会列出所有需要整改的条目,供CA机构做出必要的改变。
    2. 若请求批准后,360将确认CA预置请求已批准,并可进入下一阶段。
四. 预置测试
  1. 整个测试过程一般在二个月内完,具体测试时间取决于测试中遇到的问题能否及时解决。
  2. CA机构测试完成后,确认CA预置测试已完成,等待信创SM2根信任库正式信任。
五. 正式信任
  1. 在预置测试完成后,360将正式信任CA机构请求预置的证书,随360安全浏览器和统信UOS操作系统正式版本发布。
360信任的SM2根证书
机构 根证书 有效期 详情
  • 为什么浏览器中会出现不安全警示?
    当某个网站采用的是不安全的HTTP协议时,地址栏会出现一个灰色锁图标
    当某个网站采用的是不安全的HTTP协议,同时页面中需要您填写账号、密码等敏感信息时,360浏览器会做进一步警示,出现一个黄色提示条,这是为了提醒您,如果您输入这些信息,尤其是当您处于公共WiFi环境时,则它们可能被攻击者窃取。
  • 当遇到这种情况,您可以怎么做?
    当您常使用的网站出现上述提示时,为防止造成不必要的财产损失和信息流失,您可以尝试在地址栏中的网址之前输入“https://”——有些网站提供更安全的https页面,但需要您如此操作来进行重定向(对于不支持https协议的网站来说,此操作是无效的)。您也可以尝试联系网站管理员,要求他们提供安全的连接。
    当然您也可以选择在连接不安全的情况下,继续使用这个网站,甚至输入账号密码等信息,但其中的风险请您知悉;当您选择这样操作时,请尽量避免使用公共网络环境。另外,您需要掌握一些更安全的上网小技巧,比如为这个HTTP网站设置一个与其他重要网站不同的密码,以保护您在其他网站的信息安全。
    当出现上述黄色提示条但是您选择信任该网站时,您可以点击“我知道了”关闭它;也可以点击“不再提示”忽略此类提示,但是我们强烈建议您不要这样做,因为它可以在您处于不安全的网络连接时,给予您及时的提醒。
  • 浏览器地址栏图标有什么含义?
    :您与网站的连接是安全的且其证书在信创SM2根证书计划内;
    :您与网站的连接是安全的但其证书不在信创SM2根证书计划内;
    :您所在的网页采用了国密SSL协议,但网页中包含不安全的资源,比如页面中含有链接采用HTTP协议的图片;
    :您访问网站的服务器证书不受信任,请谨慎在该网站中输入个人信息。
    :您与网站的连接是安全的且其证书在360根证书计划(RSA)内;
    :您与网站的连接是安全的但其证书不在360根证书计划(RSA)内;
    :您所在的网页采用了HTTPS协议,但网页中包含不安全的资源,比如页面中含有链接采用HTTP协议的图片;
    :您访问网站的服务器证书不受信任,请谨慎在该网站中输入个人信息。
  • HTTPS协议是什么?
    Web浏览器和网站服务器之间传递信息时,如果采用HTTP协议(超文本传输协议),内容会以明文方式传送,没有任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息。因此,HTTP协议不适合传输一些敏感信息,比如:信用卡号、密码等支付信息。
    为了解决HTTP协议的这一缺陷,需要使用另一种协议:HTTPS协议(安全套接字层超文本传输协议),为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。
  • 为什么会出现证书错误?
    证书有问题或网站对证书的使用有问题时出现。360浏览器只是在接收到证书存在的问题后,向您提示有关证书错误的警告,可帮助您确保信息更安全。
  • 我可以访问具有证书警告的网站吗?
    你可以通过单击证书风险拦截页面上的“忽略警告,继续访问”继续访问此网站,但不建议这么做。如果在证书风险提示页面选择了忽略警告并转到了含有错误证书的网站,360浏览器将暂时记住该证书错误的忽略,您后续访问该站点不会再出现该证书的阻止页面(清理缓存等操作会忘记该忽略)。但地址栏“安全状态”栏中将继续显示“证书风提示,地址栏提示并不影响访问和使用该站点。
  • 访问经常访问的网站时出错,我该做什么?
    • 排查是否由于网址录入错误导致的证书风险提示。
    • 检查操作系统日期和时间是否正确。
    • 错误的操作系统时间,可能不在证书有效时间内,导致证书过期或无效,从而出现证书风险提示。

    • 检查网站证书是否过期或被撤销。
    • 如果网站所使用证书过期或被撤销,则需要网站站长或管理员联系证书颁发机构续订证书才能继续使用该网站。这是网站相关的问题,在浏览器中无法解决。如果您在以前成功访问过的网站上遇到错误,请联系该网站或网络管理员以报告此问题。

  • 常见的证书错误?
    证书过期:访问的网站使用的安全证书已过期或还未生效。点击查看证书过期示例
    证书过期原因:
    • 系统日期及时间错误:多个站点访问出现证书错误时,可能是由于系统日期错误导致,调整为正确系统日期及时间后可以解决。
    • 证书签发有效期结束:需要站长或站点工作人员联系证书颁发机构续订证书才能继续使用该网站。这是网站相关的问题,在浏览器中无法解决。如果您在以前成功访问过的网站上遇到错误,请联系该网站或网络管理员以报告此问题。
    错误主机:访问的网站使用的安全证书是为其他网站地址颁发的。
    假设证书是颁发给a.com,你访问的b.com使用了原本颁发给a.com的证书,即会出现该问题。点击查看错误主机示例
    错误主机出现的原因:
    • 站点配置证书出错
    • 站点非法使用了其他网站的证书
    自签名/不受信任:访问的网站使用的安全证书不是由受信任的证书颁发机构颁发的。点击查看不受信任的证书示例
    证书被撤销:访问的网站使用的安全证书已被证书颁发机构吊销。点击查看被撤销证书示例
    证书被颁发机构已经吊销,一般是由于证书颁发机构发现某人获取证书所提供的身份信息是假的,则该证书将被吊销。证书被吊销后,会将其移到“不信任 的证书”文件夹并且无法再使用。
    弱签名:网站使用的证书采用了弱签名算法,目前常见的弱签名算法为SHA-1点击查看SHA-1证书示例
    这种情况下网站使用的安全证书有可能被破解伪造,导致访问使用SHA-1证书网站的用户可能正在与攻击者连接。目前证书颁发机构已停止签发SHA1-1证书、微软及谷歌等浏览器均以停止支持SHA-1证书。
    可点击查看或搜索相关SHA-1证书新闻:
  • 站长如何获取SSL证书?
    如果经排查确定,网站是由于证书过期、证书被撤销、证书不受信任等原因造成证书错误,网站管理者可通过证书颁发机构(CA)重新申请SSL证书,替换部署到网站服务器上,解决证书错误问题。
    wosign

    机构名称:沃通电子认证服务有限公司

    机构官网:https://www.wosign.com

    机构资质:工信部许可CA机构

    证书名称:SSL证书

    申请证书:立即申请

    沃通CA提供全球可信的SSL证书,支持360、谷歌、火狐、Safari等各类浏览器和iOS、安卓等移动终端,支持Java和老设备,具备广泛兼容性;支持高强度双向传输加密、认证服务器真实身份,防止数据泄露、数据篡改、流量劫持和钓鱼网站;支持SM2和RSA双证书应用,支持SM2算法和RSA算法自适应SSL加密。

    wosign

    机构名称:华测电子认证有限责任公司

    机构官网:https://www.hnca.com.cn

    机构资质:工信部许可CA机构

    证书名称:SSL证书

    申请证书:立即申请

    华测CA提供的SSL证书,支持SM2国产密码算法及国密套件来实现加密传输,支持SM2和RSA双证书模式,实现高强度双向加密传输,防止传输数据被泄露或者篡改,对网站服务器进行真实身份认证。现在它被广泛用于网上安全敏感的通讯。

    wosign

    机构名称:浙江省数字安全证书管理有限公司

    机构官网:https://www.zjca.com.cn

    机构资质:工信部许可CA机构

    证书名称:SSL证书

    申请证书:立即申请

    浙江CA提供的SSL证书,支持网站高强度双向加密传输,防止传输数据被泄露或者篡改,对网站服务器进行真实身份认证;采用SM2和RSA双证书模式,根据用户采用的不同浏览器自适应选择加密套件和加密证书。

    网站管理者还可通过 免费检测工具 检测SSL证书部署安全性,防止证书错误。
360 Browser Root Certificate Program
360 is a security company in China and has always been working on the secure development of the Internet.
Over the last years, the Internet environment has become increasingly complex. With the rapid development of the Internet Infrastructure and the web, certificates management are more and more a burden to the Public Key Infrastructure (PKI) and digital certificate security issues are drawing more and more concerns worldwide. Web Browser vendors are facing this situation. The users only focus on the content of the web pages, but know little about what is going on behind the scenes.
Newly generated and revoked certificates from each CA everyday have increased to a considerable amount while overissue, misissuance and unconscious trust happen from time to time. Certificate’s reliability and authenticity cannot be effectively validated. In order to address these issues, CAs have implemented some methods for a better management, but sometimes is difficult to rely on them, meaning that there are still unresolved security issues related to certificates management. In order to enhance our ability to respond to these issues, by improving the efficiency of problem processing, reducing the risk cycle and clearly identifying that a certificate of a website is issued by a specific CA to help users identify trusted certificates for security reasons, 360 has decided to establish its own Root Certificate Program.
Usually 360 browsers trust the root CA certificates from the store of the underlying operating system but now will configure its own root store. 360 reserves the right to remove any certificate.
360 Browser Root Certificate Program is primarily intended for 360 browsers.
For browser bugs: kefu@360.cn
For CA root store: caprogram@360.cn
360 Browser CA Policy
Version 1.2
  1. Introduction
  2. This is the official 360 Browser CA Policy. This policy is intended initially for end user certificates issued by CAs and used by web servers for SSL/TLS authentication.
    360 representatives will maintain this policy and will evaluate new requests from CAs. 360 reserves the right to make changes to this policy at any time
    360 will decide which CA certificates are included in this program independently of those accepted in the underlying operating system. For this reason it also reserves the right to not include a CA in this program or to remove it.
    360 will not charge any fee for including a CA’s certificates in this program.
  3. Certification Authorities (CAs)
  4. This section refers to technical implementations.
    All CAs must:
    1. That for any root CA certificate to be include in 360 root store, the expiration date at the date of submission must be more than 8 years.
    2. Have root CA certificates which validity time no more than 25 years after the date of submission.
    3. Ensure that all the subordinate CA certificates and end entity certificates are issued in accordance with the CA/Browser Forum Baseline Requirements and/or EV guidelines.
    4. Ensure that subordinate CA certificates no longer sign 1024 bits and use SHA-1 algorithm.
    5. Have the Extended Key Usage (EKU) in the subordinate CA certificates as defined by the CA/Browser Forum Baseline requirements
    6. Revoke a certificate according to the CA/Browser Forum Baseline Requirements. Maintain an online 24x7 repository that 360 can use to automatically check the current status of all unexpired certificates issued by the CA.
    7. Secure the networks and operations by conforming to the CA/Browser Forum Network Security Guidelines or a similar document.
    8. Enforce multi-factor authentication for all accounts capable of causing certificate issuance or implement similar technical controls operated by the CA.
    9. Comply with the RFC 6844 related to the CAA and indicate how they manage it.
    10. All end user certificates must:
    11. Contain valid OCSP, AIA and CRL URLs, and appropriate OIDs as defined by the CA/Browser Forum documents.
    12. Verify that all of the information that is included remains current and with a correct validity period, this is 825 days or less
  5. Documentation
  6. This section refers to the CPS (Certification Practice Statement) and CP (Certificate Policy) documents that every CA shall have and maintain. Also, all the audit information provided by the auditor.
    All CAs must:
    1. Maintain its own CP/CPS and ensure that they are disclosed in a 7 X 24 available online mechanism.
    2. Ensure that the CP/CPS is in conformance with the latest version of CA/Browser Forum Baseline Requirements.
    3. Submit audit reports for all the roots included in this program to 360 in an annual basis. The CAs must be audited under one of the audit schemes specified in the CA/Browser Baseline requirements or extended validation guidelines.
    4. Provide audits covering all the subordinate CA certificates and cross-signed certificates signed by the CA, indicating the whole hierarchy.
    5. Assign an official contact and provide detailed contact information to 360.
    6. Notify 360 at least 30 days in advance when the ownership control of the CA’s certificate(s) changes, or when ownership control of the CA’s operations changes.
    7. Notify 360 within 24 hours when a serious security issue like root compromise, infrastructure fault or misissuance occurs and provide an incident report to 360.
    8. Ensure that the CP/CPS clearly specify the procedure(s) that the CA employs to verify all the information contained in the end user certificate according to subsection 3.2.2 of the CA/Browser Forum Baseline Requirements.
360 Browser Root Inclusion Process
The 360 Browser Root Inclusion Process consists of 5 phases, related to CA root inclusion request, information verification, decision on inclusion, code change for inclusion and testing and formal approval.
In order for a root certificate to be included, the CA must conform to the 360 Browser CA Policy and provide all the documentation required. 360 representatives will review this documentation.
CA root inclusion request
  1. The organization that is applying for the inclusion must be a legal Certification Authority in its country.
  2. The CA root inclusion request must be filed in the name of the organization. An official representative of the CA must submit and participate in the root inclusion request, communicate with 360 representatives to address any issues.
  3. The CA representative will send an email with all the necessary information to 360 to submit a formal request.
  4. The CA must complete the CA Information Form, which includes general information about the CA, technical information about each root certificate, CA hierarchy information for each root certificate and information about policies and practices.
  5. The CA shall be sure that all documentation and audit reports meet the requirements in CA/Browser Forum Baseline Requirements.
Information verification
  1. 360 will assign a representative to review and verify the information submitted by the CA. 360 may ask for additional information if it is needed. The duration of this phase depends on the completeness of the information provided and the CA’s responsiveness in providing further information when asked for it.
  2. Review the root certificate to make sure that it is provided in accordance with the CA/Browser Forum Baseline Requirements and applicable CRL, AIA and OCSP services are running accordingly.
  3. Review the CP/CPS provided by the CA to ensure it is in conformance with the current version of Baseline Requirements, regularly updated and 24 x 7 online available.
  4. Review the audit documents to make sure that meet the 360 Browser CA Policy.
  5. For those requests to enable EV issuance, 360 will check all practices to ensure that they are in conformance with the CA/Browser Forum’s EV Guidelines.
  6. When in this stage, the submitted information is unclear or in doubt, 360 may ask for additional information or clarification.
Decision on inclusion
  1. If there are no open issues, and there is general agreement that you comply with 360 policy requirements, then 360 will move the request into the Decision on Inclusion Phase.
  2. The representative of 360 Browser Root Certificate Inclusion Program reserves the right to make the final decision on a root inclusion request.
    1. If the request is not approved, 360 will list all the items that need to be improved for the CA to make the necessary changes.
    2. If the request is approved, 360 will confirm the approval and move into the next phase.
Code change for inclusion and testing
  1. This phase is generally completed within 1 to 2 months, and the duration of the testing depends on how quickly the issues found in the process can be resolved.
  2. After the completion of the testing, 360 will confirm the success and the CA will need to wait for the formal inclusion of the root into the 360 Trusted Root Store.
Formal approval
  1. After the testing, 360 will formally trust the root which the CA requests for inclusion, and will include it into the 360 Trusted Root Store in the next release.
360 Trusted Root Certificates
CA Root certificate Validity period Details
  • Why do alerts appear in the browser?
    Your connection to a site with HTTP protocol is not secure and then the icon will appear in the address bar.
    When you fill in personal information such as account number and/or password on the page with HTTP protocol, 360 browsers will notify you with additional warnings. It reminds you that personal information can be probably stolen by an attacker, especially when you are in a public WiFi environment.
  • What can you do under these situations?
    When you see alerts or warnings as mentioned above, you can try to find a secured page by entering https:// before the URL in the address bar to prevent unnecessary property damage and loss of information.
    Of course, you can also choose to continue to use this website even the connection is not secure; however, the risks involved should be considered. If you decide to continue, please avoid using public networks as much as possible. In addition to avoid further issues do not use the same password for all websites and change it periodically.
    When the alert or warnings appear and you choose to continue, you can click "I know" to close it; you can also click "Never popup" to ignore such tips, but we strongly recommend you not to do it because it can give you a timely reminder once you are on an unsecured network connection.
  • What do the icons in browser address bar mean?
    : Your connection to the website is secure and the certificate is in the 360 CA program;
    : Your connection to the website is secure but the certificate is not in the 360 CA program;
    : The webpage you are visiting is using HTTPS protocol; however, it contains not secured resources. For example, the page contains images with HTTP protocol.
    : Your connection to the website is not secure, it´s not using HTTPS protocol. Please be careful to enter any personal information on this website.
  • What is HTTPS protocol?
    When transferring information between the web browser and the web server using HTTP protocol (hypertext transfer protocol), the content is transmitted in clear text, and there is no way to encrypt the data. If the attackers intercepts this information between the web browser and the web server, they can directly read the information. Therefore, the HTTP protocol is not suitable for transmitting some important information, such as credit card numbers, passwords, etc.
    To address this issue , a more secure protocol shall be adopted. The HTTPS protocol (Secure Sockets Layer Hypertext Transfer Protocol)-with SSL protocol added to HTTP, encrypts the communication between the browser and the server.