Apple Root Certificate Program

Note: This version comes into effect August 15, 2023
Apple uses public key infrastructure (PKI) to secure and enhance the experience for Apple users. Apple operating systems and applications (such as Safari and Mail) use a common store for root certificates; see https://support.apple.com/kb/HT209143 and https://support.apple.com/kb/HT212865. Apple requires certification authority (CA) providers to meet certain criteria, as documented herein.

1. Program Requirements

1.1 Audit Requirements

CA providers may fall into one or more of the below categories and must meet the obligations related to all certificate purposes for which they are enabled within the Apple Root Program.

CA providers must provide audit reports in the Common CA Database (CCADB).
Note: The presence of qualifications in an audit report is not, by itself, considered reason to remove a CA provider from the Apple Root Program. The purpose of audits is to honestly and thoroughly assess a CA provider’s compliance with requirements which are necessary to assure a secure and stable ecosystem. Audit findings, including qualifications, can help to identify opportunities for improvement, whether for individual CA providers or for the wider industry as a whole.

1.1.1 All CA Providers

CA providers must ensure their CAs are audited against the current version of at least one of the below criteria at least annually:

1.1.2 TLS CA Providers

CA providers must ensure their Transport Layer Security (TLS) enabled root CAs and all subordinate CAs capable of issuing TLS certificates are audited against the current version of at least one of the below sets of criteria at least annually:

1.1.3 EV TLS CA Providers

CA providers must ensure their Extended Validation (EV) enabled root CAs and all subordinate CAs capable of issuing EV TLS certificates are audited against the current version of at least one of the below sets of criteria at least annually:

1.1.4 S/MIME CA Providers

Effective December 1, 2024, CA providers must ensure their S/MIME enabled root CAs and all subordinate CAs capable of issuing S/MIME certificates have been and will continue to be audited against the current version of at least one of the below sets of criteria at least annually:
To further clarify expectations:
Note: Apple expects its S/MIME CA providers to be proactively seeking to comply with the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates. In order to ensure minimal disruption to currently included S/MIME CA providers, and in order to enable uninterrupted issuance of S/MIME certificates by these CA providers as the S/MIME Baseline Requirements come into effect, Apple expects audits to be conducted sufficiently early in the lifecycle of the Requirements to provide confidence that pre-existing CA providers have successfully transitioned their S/MIME CA systems into a compliant state.

1.1.5 Lifecycle Event Reporting

CA providers must ensure all keys intended for use in a CA Certificate are included in lifecycle reports as part of their annual auditing procedures. When Lifecycle Events have occurred during an audit period, they must be addressed either in:
Such reporting must minimally cover the following Lifecycle Events:

1.2 Audit Engagement Requirements

1.2.1 Auditor Annual Training

CA providers must ensure auditors involved in external audit engagements undergo and/or have undergone annual training specific to the subject matter assessed within the Audit Criteria outlined in section 1.1.
Note: CA providers and auditors are encouraged to reach out to the Apple Root Program with questions and for recommendations. By way of example, if the auditor has undergone training to review the changes made to the Audit Criteria they’re assessing, that would meet this requirement. CA providers are not required to share with Apple the evidence used to verify Auditor Annual Training compliance.

1.2.2 Firm and Auditor Qualifications

CA providers must ensure audits used to comply with this policy are performed by entities licensed or otherwise permitted to provide assurance services in the country(ies) where the assessment is performed, for the entirety of the audit engagement’s duration. 
Note: CA providers are not required to share with Apple the evidence used to verify Firm and Auditor Qualifications meet these requirements.

1.2.3 Additional Requirements or Obligations

Note: Due to how audit engagements are structured, additional audit engagements, the appointment or rejection of an auditor, and a detailed controls report are actions that would typically apply to a future audit.

1.2.4 Incidents

CA providers must ensure that audit reports include information regarding all incidents, as described and defined below under Section 3 “Incidents” and as required by section 5.1 of the CCADB Policy (https://www.ccadb.org/policy).

1.3 Standards and Policy Document Compliance Requirements

1.3.1 All CA Providers

CA providers must strictly adhere to their Certificate Policy (CP) and/or Certification Practices Statement (CPS) document(s) as disclosed within the CCADB (and not marked as “Deleted”).
Note: This extends to all policy documents the CA provider publishes in relation to its CAs included in the Apple Root Program, such as TSPS documents.
CA providers must strictly adhere to the current version of the CCADB Policy (https://www.ccadb.org/policy).

1.3.2 TLS CA Providers

TLS CA providers must constantly maintain compliance with the current version of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (TLS Baseline Requirements).

TLS CA providers must incorporate and commit to compliance with the current version of the CA/Browser Forum’s Baseline Requirements in their CP and/or CPS documents.

1.3.3 EV TLS CA Providers

EV TLS CA providers must constantly maintain compliance with the current version of the CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation Certificates (EV Guidelines).

EV TLS CA providers must incorporate and commit to compliance with the current version of the CA/Browser Forum’s EV Guidelines in their CP and/or CPS documents.

1.3.4 S/MIME CA Providers

Effective September 1, 2023, S/MIME CA providers must constantly maintain compliance with the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates (S/MIME Baseline Requirements).
Note: This also requires that end-entity S/MIME certificates must be issued from a CA Certificate compliant with the S/MIME Baseline Requirements.
Effective September 1, 2023, S/MIME CA providers must incorporate and commit to compliance with the current version of the CA/Browser Forum’s S/MIME Baseline Requirements in their CP and/or CPS documents.

1.4 Communication Requirements

1.5 Inclusion Requirements

2. Policy Requirements

Note: For effective dates related to certificate issuance, the requirement is enforced for certificates issued on or after the specified date at 00:00:00 UTC.

2.1 General

2.1.1 CA Disclosure

Effective April 1, 2022, CA providers must disclose in the CCADB all CA Certificates which chain up to their CA Certificate(s) included in the Apple Root Program.

2.1.2 Full CRLs

Effective October 1, 2022, CA providers must populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" on Root and Intermediate Certificate records, within 7 days of the corresponding CA issuing its first certificate. This requirement applies to each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program.

2.1.3 Single-purpose Root CAs

Effective April 15, 2024, all CA providers applying to the Apple Root Program must submit only Root CA Certificates dedicated to a single purpose. Valid certificate purposes are:
Note: In a future version of the Apple Root Program Policy, it is expected that already-included Root CA Certificates which do not comply with the above guidance will be removed from the Apple Root Program.

2.2 TLS

2.3 S/MIME

3. Incidents

Failure to comply with the above requirements in any way is considered an incident. CA providers must report such incidents to the Apple Root Program at certificate-authority-program@apple.com with a full incident report. This report can be shared directly or as a link from a public disclosure (e.g. Bugzilla).

Of paramount importance for CA providers when submitting incident reports and participating in all follow-up discussion are: 

4. Submission Process

To begin the submission process, request access to the CCADB and create a Root Inclusion Request Case in the CCADB. Once complete, e-mail certificate-authority-program@apple.com with the details of your Root Inclusion Request Case. CA providers will be contacted if any additional information is required, and when consideration of the Root Inclusion Request is complete. For more information on the CCADB, please see https://www.ccadb.org/cas.

5. Root Acceptance

Apple accepts and removes Root CA Certificates and CA providers as it deems appropriate at its sole discretion. Apple prioritizes Root Inclusion Requests as it deems appropriate at its sole discretion.