360浏览器根证书计划
360是中国互联网安全公司,360团队一直致力于互联网的安全发展。
在过去的几年里,互联网环境日趋复杂。随着互联网网络基础设施和网络的在快速发展,证书管理的问题越来越困扰公钥基础设施(PKI),数字证书安全问题越来越受到国内外用户的关注。Web浏览器面临着艰巨情况,用户只专注于页面的内容,但是对在幕后发生的事情不甚了解。
每天各个CA机构新增和吊销的证书已呈现一定的数量级,证书滥发、错发、无意信任等情况时有发生,证书可信性,真实性无法及时有效的校验。为了解决这些问题,CA机构已经实现了一些更好的管理方法,但有时候很难依赖它们,这意味着证书管理方面还存在一些未解决的安全问题。为了增强我们对那些证书问题的应对能力,可以通过提高问题处理的效率、缩短风险周期,有效识别出网站证书是由具体CA机构签发的真实性,进一步帮助用户识别可信安全证书,360决定创建自己的根证书计划。
360浏览器通常信任底层操作系统信任的根证书,但现在也会配置自己的根信任库。360有权移除任何证书。
360浏览器根证书计划主要适用于360浏览器。
联系我们:caprogram@360.cn
360浏览器根证书认证策略
1.2版本
  1. -介绍
  2. 下面是360浏览器根证书认证的策略,该策略是为使用web服务器由CA发布的终端用户证书用于SSL / TLS认证。
    360官方负责人将维护这一策略并评估来自CA的新请求,360有权随时修改该策略。
    360将决定哪些CA证书可以加入根证书计划,独立加入系统根信任库,因此,360也有权决定在根证书计划中移除某个CA证书。
    CA根证书申请加入360浏览器根证书计划,360不会收取任何费用。
  3. -认证机构(CAs)
  4. 这一部分主要是指技术实现
    所有CA机构必须:
    1. 申请加入360根证书库的CA机构根证书,从提交申请开始计算,根证书的有效期至少超过8年。
    2. 从根证书提交之日起,不超过25年有效期。
    3. 确保签发的所有子CA、用户证书都符合CA/Browser Forum Baseline Requirements的相关规定,并且/或者EV准则。
    4. 根证书的下属子CA不再签发1024位的服务器证书和SHA算法。
    5. 子CA必须有CA/Browser Forum Baseline Requirements所定义的扩展密钥用法
    6. 根据CA/Browser Forum Baseline Requirements来吊销证书,CA必须24x7维持储存库在线,以便应用软件能够自动查询CA颁发的所有未过期证书的当前状态。
    7. 遵守CA /浏览器论坛网络安全指南或类似文件的要求,以确保网络和操作安全。
    8. 加强多因素验证,对有可能导致证书发布或执行相似技术控制的CA账户采取多因素验证。
    9. 遵守与CAA相关的RFC 6844,并说明如何管理。
    10. 所有的终端用户证书必须:
    11. 包含有效的OCSP URL、AIA URL和CRL URL,以及由CA/Browser Forum Baseline Requirements所定义的适用OIDs。
    12. 验证所包含的所有信息均为当前,且在正确的有效期内,即至少825天。
  5. -文件
  6. 这一部分是指,每一个CA都应持有和维护CPS(认证操作规范)和CP(证书策略)。它还指出了当出现问题时该如何做出反应。
    所有CA机构必须:
    1. CA必须有自己的CP/CPS,并保证7x24小时在线公开机制,可随时浏览。
    2. 确保CP/CPS符合CA/Browser Forum Baseline Requirements的最新要求。
    3. CA机构必须每年向360提供所有根证书的审计报告,CA机构必须采取CA/Browser Baseline requirements或者扩展验证准则规定方案中的一种进行审计。
    4. CA审计报告中,必须包括对所有子CA,交叉根进行审计的部分,指明整个层级结构。 16. 指定官方联系人,并将其详细信息提供给360。
    5. 当CA的证书或CA的运营所属权发生改变时,至少要提前30天通知360。
    6. CA发生如根证书私钥泄露、基础设施故障、签发错误的用户证书等严重事件时,CA应不晚于24小时通知360,并向360提供完整的事件报告。
    7. 确保CP/CPS 明确规定了流程,CA是根据CA/Browser Forum Baseline Requirements的3.2.2.4小节来验证最终用户证书中包含的所有信息。
360浏览器根证书认证流程
360浏览器根证书认证过程,包括CA申请、信息验证、批准请求、预置测试、正式信任五个部分。
为完成根证书预置,CA机构必须遵守360浏览器根证书认证策略的规定,并提供所有需要的材料,360浏览器根认证项目负责人将会对这些材料进行审核。
一. CA申请
  1. 申请加入的组织必须是一个合法的证书颁发机构(CA)。
  2. 根证书预置申请必须以公司名义提出,CA机构的官方代表必须参与到根证书预置的申请工作中,且有能力与360项目负责人沟通处理任何问题。
  3. CA代表将会向360发送一封邮件,内含所有必要的申请信息,以提交正式请求。
  4. CA必须填写根证书预置申请表,包括CA机构的基本信息、根证书的技术参数、根证书的层级信息、策略几个部分内容。
  5. CA确保提交的所有文件、审计报告,符合 CA/Browser Forum Baseline Requirements的规定。
二. 信息验证
  1. 360将指定官方负责人处理CA信息审核。如果有需要,360会要求提供额外的信息。这个过程一般在一个月内完成,具体持续时间取决于CA提供的信息的完整性和CA对问题的反应时间。
  2. 检查CA提供的根证书文件是否符合CA/BR要求,相关的CRL、AIA、OCSP服务是否正常运行。
  3. 检查CP/CPS内容是否符合BR对CA机构的要求,确保CP/CPS跟进BR的最新版本,定期进行更新,并保证CP/CPS能随时在线浏览。
  4. 检查CA提供的审计报告是否满足360根认证策略中对于审计的要求。
  5. 如果CA发布EV SSL证书,360将检查CA各项操作是否符合 CA/Browser Forum's EV guidelines。
  6. 在这一阶段,对于CA提交的材料有不清楚或有疑问的地方,360可能会要求提供额外的信息或做进一步澄清。
三. 批准请求
  1. 若CA机构的业务操作、管理等情况得到360的普遍认可,360将把CA根预置请求进入批准阶段。
  2. 对于CA机构的根预置请求,360浏览器根证书计划项目负责人具有最终决定权。
    1. 若请求未批准,360将会列出所有需要整改的条目,供CA机构做出必要的改变。
    2. 若请求批准后,360将确认CA预置请求已批准,并可进入下一阶段。
四. 预置测试
  1. 整个测试过程一般在二个月内完,具体测试时间取决于测试中遇到的问题能否及时解决。
  2. CA机构测试完成后,确认CA预置测试已完成,等待360浏览器根信任库正式信任。
五. 正式信任
  1. 在预置测试完成后,360将正式信任CA机构请求预置的证书,随360浏览器正式版本发布。
360信任的根证书列表
机构 根证书 有效期 详情
  • 为什么浏览器中会出现不安全警示?
    当某个网站采用的是不安全的HTTP协议时,地址栏会出现一个灰色锁图标
    当某个网站采用的是不安全的HTTP协议,同时页面中需要您填写账号、密码等敏感信息时,360浏览器会做进一步警示,出现一个黄色提示条,这是为了提醒您,如果您输入这些信息,尤其是当您处于公共WiFi环境时,则它们可能被攻击者窃取。
  • 当遇到这种情况,您可以怎么做?
    当您常使用的网站出现上述提示时,为防止造成不必要的财产损失和信息流失,您可以尝试在地址栏中的网址之前输入“https://”——有些网站提供更安全的https页面,但需要您如此操作来进行重定向(对于不支持https协议的网站来说,此操作是无效的)。您也可以尝试联系网站管理员,要求他们提供安全的连接。
    当然您也可以选择在连接不安全的情况下,继续使用这个网站,甚至输入账号密码等信息,但其中的风险请您知悉;当您选择这样操作时,请尽量避免使用公共网络环境。另外,您需要掌握一些更安全的上网小技巧,比如为这个HTTP网站设置一个与其他重要网站不同的密码,以保护您在其他网站的信息安全。
    当出现上述黄色提示条但是您选择信任该网站时,您可以点击“我知道了”关闭它;也可以点击“不再提示”忽略此类提示,但是我们强烈建议您不要这样做,因为它可以在您处于不安全的网络连接时,给予您及时的提醒。
  • 浏览器地址栏图标有什么含义?
    :您与网站的连接是安全的且其证书在360根证书计划内;
    :您与网站的连接是安全的但其证书不在360根证书计划内;
    :您所在的网页采用了HTTPS协议,但网页中包含不安全的资源,比如页面中含有链接采用HTTP协议的图片;
    :您与网站的连接是不安全,请谨慎在该网站中输入个人信息。
  • HTTPS协议是什么?
    Web浏览器和网站服务器之间传递信息时,如果采用HTTP协议(超文本传输协议),内容会以明文方式传送,没有任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息。因此,HTTP协议不适合传输一些敏感信息,比如:信用卡号、密码等支付信息。
    为了解决HTTP协议的这一缺陷,需要使用另一种协议:HTTPS协议(安全套接字层超文本传输协议),为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,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.
Contact us: 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.4 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.