- Notifications
You must be signed in to change notification settings - Fork3
License
GoogleChrome/chromerootprogram
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Google Chrome relies on Certification Authority systems ("CAs") to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website's certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA recognized by Chrome or a user's local settings can cause users to see warnings and error pages.
When making HTTPS connections, Chrome refers to a list of root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a "Root Store." CA certificates included in theChrome Root Store are selected on the basis of publicly available and verified information, such as that within the Common CA Database (CCADB), and ongoing reviews by the Chrome Root Program.
In Chrome 105, Chrome began a platform-by-platform transition from relying on the host operating system's Root Store to its own on Windows, macOS, ChromeOS, Linux, and Android. This change makes Chrome more secure and promotes consistent user and developer experiences across platforms. Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS. Learn more about the Chrome Root Store and Chrome Certificate Verifierhere.
The Chrome Root Program Policy establishes the minimum requirements for self-signed root CA certificates to be included as trusted in a default installation of Chrome. This GitHub repository contains a Markdown-formatted version of the authoritative version availablehere.
Any questions regarding the Chrome Root Program Policy can be directed to chrome-root-program [at] google [dot] com.
The site is deployed on commits tomain
. To add a new policy revision:
- Archive the current version in
content/policy-archive/
(create the directoryand copy it to the proper index.md file). - Update
config.yaml
:- Update
context.versions
array so that the path for the now archivedversion is no longer marked ascurrent
- Add a new entry at the bottom of the array for the next version, with anarchive path,
path: content/policy-archive/policy-version-NEW-VERSION
.The file and folder do not need to exist. - Bump
context.current_version
to the next version value. It should matchthe version number in at the end of the versions array. Be sure all versionnumbers are in quotes so they are interpreted as strings, not floats.
- Update
- Update
content/index.md
with the new content. This way the PR will show adiff of the new policies in index.md.
This can all be done in a single pull request. The diff in the PR will show the diff between the two policy versions.
Links in Markdown to other documents in this repository should end inmd
, e.g.[Policy](index.md)
. Links in raw HTML, e.g.<a href=/moving-forward-together>
should not. This make the links in the Github UIwork for Markdown, and results in a correctly-compiled site. Hardcoded HTMLlinks will not resolve correctly in previews.
About
Resources
License
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Releases
Packages0
Uh oh!
There was an error while loading.Please reload this page.