RFC4158. IETF(英語). all of the end entities and relying parties use a single "Root CA" as their trust anchor. If the hierarchy has multiple levels, the Root CA certifies the public keys of intermediate CAs (also known as subordinate CAs). These CAs then certify end entities' (subscribers') public keys or may, in a large PKI, certify other CAs.缺少或|url=為空 (幫助)
Repository of Documentation and Certificates. Google Trust Services. [2017-07-15]. (原始內容存檔於2020-12-19) (英語). The Google Public Key Infrastructure (「Google PKI」), has been established by Google Trust Services, LLC (「Google」), to enable reliable and secure identity authentication, and to facilitate the preservation of confidentiality and integrity of data in electronic transactions.
Key Ceremony. Digi-Sign. [2017-07-20]. (原始內容存檔於2020-10-26) (英語). A Key Ceremony is only required when your organisation wishes to achieve your own independent root, or intermediate, Certificate Authority. This typically occurs where an organisation wants to create and own its own Root CA for reasons relating to compliance to specific standards (e.g. ISO 27001, WebTrust, EU Qualified Certificates, etc). A Root Key Ceremony is a procedure where a unique pair of Public and Private Root Keys is generated. Depending on your requirements and specifications, the generation of the Root Keys may require notarisation, legal representation, witnesses and "Key Holders" to be present
Mozilla Root Store Policy. Mozilla. [2017-07-15]. (原始內容存檔於2017-04-15) (英語). When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla includes with such software a set of X.509v3 root certificates for various Certification Authorities (CAs). The included certificates have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to anchor a chain of trust for certificates used by SSL servers and S/MIME email users without having to ask users for further permission or information.
Microsoft Trusted Root Certificate: Program Requirements. 微軟(英語). The Microsoft Trusted Root Certificate Program ("Program") supports the distribution of qualifying root certificates in Microsoft Windows and other Microsoft Products and Services.
Apple Root Certificate Program. 蘋果公司. [2017-07-15]. (原始內容存檔於2017-03-20) (英語). Apple uses public key infrastructure (PKI) to secure and enhance the experience for Apple users. Apple products, including our web browser Safari and Mail.app, use a common store for root certificates. Apple requires root certification authorities to meet certain criteria[...]
Including Certificate Authority Root Certificates in Java. 甲骨文公司. [2017-07-15]. (原始內容存檔於2019-11-27) (英語). In order to protect Oracle's Java SE customers from security issues related to the use of public key infrastructure (PKI) certificates while enhancing their overall experience, Oracle requires that all root certificates authorities meet the following criteria before applying for inclusion of their root certificates in Oracle’s Java Runtime Environment (JRE).
Adobe Approved Trust List. Adobe Systems. [2017-07-15]. (原始內容存檔於2018-06-02) (英語). Essentially, both Acrobat and Reader have been programmed to reach out to a web page to periodically download a list of trusted "root" digital certificates. Any digital signature created with a credential that can trace a relationship ("chain") back to the high-assurance, trustworthy certificates on this list is trusted by Acrobat and Reader.
EU Trusted List now available in Adobe Acrobat!. Adobe Systems. 2015-10-26 [2017-07-15]. (原始內容存檔於2017-03-20) (英語). Adobe is delighted to announce the completion of our work to support and integrate the EU Trusted Lists (EUTL) into Adobe Acrobat and Acrobat Reader. For the first time, citizens, governments and businesses across the world will have easy access to electronically signed documents based on EU qualified certificates in the ubiquitous Adobe Acrobat and Acrobat Reader software.
EU Trusted Lists. 歐洲聯盟執委會. 2017-05-09 [2017-07-15]. (原始內容存檔於2020-08-25) (英語). Under the Regulation (EC) No 910/2014/EU (eIDAS Regulation), national Trusted Lists have a constitutive effect. In other words, a trust service provider and the trust services it provides will be qualified only if it appears in the Trusted Lists. Consequently, the users (citizens, businesses or public administrations) will benefit from the legal effect associated with a given qualified trust service only if the latter is listed (as qualified) in the Trusted Lists.
PSM:Changing Trust Settings. Mozilla. 2017-05-05 [2017-07-20]. (原始內容存檔於2021-10-11) (英語). This page describes how to change the default root certificate trust settings in Mozilla products, including Firefox and Thunderbird. [...] Some browsers only display the root certificates that the user has actually used, and dynamically download new ones on demand. However, Mozilla believes it is important for users to know the root certificates that could be used, so the full set of certificates is always shown. This also allows you to edit the trust bits for any root certificates that you do not want to use.
SSL/TLS Certificates for Internal Servers. GlobalSign. 2016-09-29 [2017-07-16]. (原始內容存檔於2020-11-12) (英語). Enterprises can easily push out the necessary IntranetSSL non-public roots to their users via Group Policy Object (GPO), or other centralized management system which will make the IntranetSSL certificates trusted by their user community.
SSL Forward Proxy. 派拓網路. [2017-07-17]. (原始內容存檔於2017-12-01) (英語). The firewall uses certificates to establish itself as a trusted third party to the session between the client and the server [...] When the client initiates an SSL session with the server, the firewall intercepts the client SSL request and forwards the SSL request to the server. The server returns a certificate intended for the client that is intercepted by the firewall. If the server certificate is signed by a CA that the firewall trusts, the firewall creates a copy of the server certificate signs it with the firewall Forward Trust certificate and sends the certificate to the client [...] When the client authenticates the certificate, the SSL session is established with the firewall functioning as a trusted forward proxy to the site that the client is accessing. As the firewall continues to receive SSL traffic from the server that is destined for the client, it decrypts the SSL traffic into clear text traffic and applies decryption and security profiles to the traffic. The traffic is then re-encrypted on the firewall and the firewall forwards the encrypted traffic to the client.
SSL Forward Proxy Overview. Juniper Networks. 2016-06-14 [2017-07-17]. (原始內容存檔於2021-02-25) (英語). SSL forward proxy is a transparent proxy; that is, it performs SSL encryption and decryption between the client and the server, but neither the server nor the client can detect its presence. SSL forward proxy ensures that it has the keys to encrypt and decrypt the payload
Jeremy Schatten. Setup Squid Forward Proxy. 2016-09-09 [2017-07-17]. (原始內容存檔於2018-03-16) (英語). In this configuration, the proxy is performing what in another context would be considered a man-in-the-middle attack. The client is completely unaware that somewhere their traffic is being sent is posing as the destination, decrypting their communication, and re-encrypting it to send to the real target server. Responses are captured on-the-fly as well, and sent back to the origin server. [...] It presents a certificate valid for any domain that it generates as requests hit it in real time, and because the client needs to be configured to trust the same root CA certificate the proxy uses, will allow the connection. (Remember, any certificate trusted as a root certificate can sign valid certificates for any and all domains and paths, not just its own.)
How do certification authorities store their private root keys?. Stack Exchange. [2017-07-20]. (原始內容存檔於2021-01-22) (英語). For extra recovery, the CA is often split into a long-lived root CA which is kept offline, and a short-lived intermediate CA. Both machines are in the cage and bunker; the root CA is never connected to a network. The root CA is physically accessed, with dual control (at least two people together, and video recording) on a regular basis, to emit the certificate for the intermediate CA