What is apple root certificate

Program Requirements

Note: This version comes into effect December 1, 2021

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. Apple requires certification authority (CA) providers to meet certain criteria, which include:

• CA providers must ensure their CAs are audited against at least one of the below criteria at least annually:
  • (Preferred) WebTrust Principles and Criteria for Certification Authorities
  • (Accepted on a case-by-case basis) ETSI EN 319 411-1 NCP or NCP+
• CA providers must ensure their Transport Layer Security (TLS) enabled root CAs and all subordinate CAs capable of issuing TLS certificates are audited against at least one of the below sets of criteria at least annually:
  • (Preferred) WebTrust Principles and Criteria for Certification Authorities and WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
  • (Accepted on a case-by-case basis) ETSI EN 319 411-1 LCP and (DVCP or OVCP)
  • (Accepted on a case-by-case basis) ETSI EN 319 411-1 NCP and EVCP
• CA providers must ensure their Extended Validation (EV) enabled root CAs and all subordinate CAs capable of issuing EV TLS certificates are audited against at least one of the below sets of criteria at least annually:
  • (Preferred) WebTrust Principles and Criteria for Certification Authorities, WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security, and WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL
  • (Accepted on a case-by-case basis) ETSI EN 319 411-1 NCP and EVCP
• CA providers must strictly adhere to their Certificate Policy (CP) and/or Certification Practices Statement (CPS) documents.
• TLS CA providers must constantly maintain compliance with the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates.
• TLS CA providers must incorporate and commit to compliance with the CA/Browser Forum’s Baseline Requirements in their CP and/or CPS documents.
• EV CA providers must constantly maintain compliance with the CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation Certificates.
• EV CA providers must incorporate and commit to compliance with the CA/Browser Forum’s EV Guidelines in their CP and/or CPS documents.
• CA providers must maintain up to date contact details in the Common CA Database (CCADB).
• CA providers are accountable for discussion and balloted changes communicated via the following:
  • CA communications from Apple (typically via CCADB)
  • CA/Browser Forum Public Discussion List (https://lists.cabforum.org/mailman/listinfo/public)
  • CA/Browser Forum Server Certificate Working Group (https://lists.cabforum.org/mailman/listinfo/servercert-wg)
  • CA/Browser Forum Validation Subcommittee (https://lists.cabforum.org/mailman/listinfo/validation)
  • CA/Browser Forum Networking Security Subcommittee (https://lists.cabforum.org/mailman/listinfo/netsec)
  • CA/Browser Forum SMIME Certificate Working Group (https://lists.cabforum.org/mailman/listinfo/smcwg-public)
• CA providers must notify Apple if they anticipate any change in control or ownership of any CA certificate (whether directly included or subordinate thereto). Do not assume inclusion is transferable.
• CA providers must strictly limit the number of roots per CA provider, especially those capable of issuing multiple types of certificates.
• A root certificate must provide broad value to Apple’s users.
• CA providers applying for inclusion in the Apple Root Program are expected to meet all Program and Policy requirements prior to submitting an application.

Policy Requirements

• 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.
• Effective April 1, 2022, S/MIME certificates must:
  • include the emailProtection EKU
  • include at least one subjectAlternativeName rFC822Name value containing an email address
  • not have a validity period greater than 825 days
  • use a signature hash algorithm of greater than or equal strength to SHA-256 (see section 7.1.3.1 and 7.1.3.2 of the CA/B Forum’s Baseline Requirements).
  • meet the following key size requirements:
    • For RSA key pairs, the modulus size must be at least 2048 bits when encoded and its size in bits must be evenly divisible by 8.
    • For ECDSA key pairs, the key must represent a valid point on the NIST P‐256, NIST P‐384 or NIST P‐521 named elliptic curve.
• Effective October 1, 2022, CA providers must populate the “Pertaining to Certificates Issued by this CA” section of the CCADB for each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program.
  • The CRL URLs provided by CAs in this section must be available for successful retrieval by Apple systems a minimum of once every 4 hours.
  • In order to populate this section for Root CA Certificates, please email the Apple Root Program (certificate-authority-program@apple.com) with the desired details and associated CCADB records.

Submission Process

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

Root Acceptance

Apple accepts and removes root certificates as it deems appropriate at its sole discretion. Apple prioritizes Root Inclusion Requests as it deems appropriate at its sole discretion.

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).

Copyright © 2021 Apple Inc. All rights reserved.

Источник

Lists of available trusted root certificates in iOS

The iOS Trust Store contains trusted root certificates that are preinstalled with iOS.

Blocking Trust for WoSign CA Free SSL Certificate G2

Certificate Authority WoSign experienced multiple control failures in their certificate issuance processes for the WoSign CA Free SSL Certificate G2 intermediate CA. Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

In light of these findings, we took action to protect users in a security update. Apple products no longer trust the WoSign CA Free SSL Certificate G2 intermediate CA.

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products trust individual existing certificates that were issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19. They will continue to be trusted until they expire, are revoked, or are untrusted at Apple’s discretion.

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

Further steps for WoSign

After further investigation, we have concluded that in addition to multiple control failures in the operation of the WoSign certificate authority (CA), WoSign did not disclose the acquisition of StartCom.

We are taking further actions to protect users in an upcoming security update. Apple products will block certificates from WoSign and StartCom root CAs if the «Not Before» date is on or after 1 Dec 2016 00:00:00 GMT/UTC.

About trust and certificates

Each iOS Trust Store listed below contains three categories of certificates:

• Trusted certificates establish a chain of trust that verifies other certificates signed by the trusted roots—for example, to establish a secure connection to a web server. When IT administrators create Configuration Profiles for iOS, these trusted root certificates don’t need to be included.
• Always Ask certificates are untrusted but not blocked. When one of these certificates is used, you’ll be prompted to choose whether or not to trust it.
• Blocked certificates are believed to be compromised and will never be trusted.

iOS Trust Store

Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Contact the vendor for additional information.

Источник

Certificates

Apple Developer Program membership is required to request, download, and use signing certificates issued by Apple.

Using certificates

In most cases, Xcode is the preferred method to request and install digital certificates. However, to request certificates for services such as Apple Pay, the Apple Push Notification service, Apple Wallet, and Mobile Device Management, you’ll need to request and download them from Certificates, Identifiers & Profiles in your developer account. Distribution certificates can be requested only by Account Holders and Admins.

For more information on how to use signing certificates, review Xcode Help.

Protecting your account and certificates

Your Apple ID, authentication credentials, and related account information and materials (such as Apple Certificates used for distribution or submission to the App Store) are sensitive assets that confirm your identity.

• Keep your Apple ID and authentication credentials secure and do not share them with anyone. To learn more, see Security and your Apple ID .
• Do not share Apple Certificates outside of your organization. To learn how to securely share them with trusted team members within your organization, see Maintain Signing Assets in Xcode Help.

Expired or revoked certificates

• Apple Push Notification Service Certificate
  You can no longer send push notifications to your app.
• Apple Pay Payment Processing Certificate
  Apple Pay transactions in your apps and on your websites will fail.
• Apple Pay Merchant Identity Certificate
  Apple Pay transactions on your websites will fail.
• Pass Type ID Certificate (Wallet)
  If your certificate expires, passes that are already installed on users’ devices will continue to function normally. However, you’ll no longer be able to sign new passes or send updates to existing passes. If your certificate is revoked, your passes will no longer function properly.
• iOS Distribution Certificate (App Store)
  If your Apple Developer Program membership is valid, your existing apps on the App Store won’t be affected. However, you’ll no longer be able to upload new apps or updates signed with the expired or revoked certificate to the App Store.
• iOS Distribution Certificate (in-house, internal-use apps)
  Users will no longer be able to run apps that have been signed with this certificate. You must distribute a new version of your app that is signed with a new certificate.
• Mac App Distribution Certificate and Mac Installer Distribution Certificate (Mac App Store)
  If your Apple Developer Program membership is valid, your existing apps on the Mac App Store won’t be affected. However, you’ll no longer be able to upload new apps or updates signed with the expired or revoked certificate to the Mac App Store.
• Developer ID Application Certificate (Mac applications)
  If your certificate expires, users can still download, install, and run versions of your Mac applications that were signed with this certificate. However, you’ll need a new certificate to sign updates and new applications. If your certificate is revoked, users will no longer be able to install applications that have been signed with this certificate. If your Mac application utilizes a Developer ID provisioning profile to take advantage of advanced capabilities such as CloudKit and push notifications, you must ensure your Developer ID provisioning profile is valid in order for installed versions of your application to run. Read more.
• Developer ID Installer Certificate (Mac applications)
  If your certificate expires, users can no longer launch installer packages for your Mac applications that were signed with this certificate. Previously installed apps will continue to run however new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate. If your certificate is revoked, users will no longer be able to install applications that have been signed with this certificate.
• Apple Worldwide Developer Relations Certification Intermediate Certificate
  The Apple Worldwide Developer Relations Certificate Authority issues certificates used by developers for signing third-party apps and Safari Extensions, and for using Apple Wallet and Apple Push Notification services.

The current Apple Worldwide Developer Relations Certification Intermediate Certificate is set to expire on February 7, 2023. The renewed certificate will be used to sign new iOS Distribution Certificates issued after September 2, 2020 for the Apple Developer Enterprise Program. Remaining certificates for all program types will be updated in the future and this page will be updated to reflect additional certificate changes. Read more.

Note: Apple can revoke digital certificates at any time at its sole discretion. For more information, read the Apple Developer Program License Agreement in your developer account.

Compromised certificates

If you suspect that your Pass Type ID certificate or Developer ID certificate and private key have been compromised, and would like to request revocation of the certificate, send an email to product-security@apple.com. You can continue to develop and distribute passes by requesting an additional certificate in your developer account.

I received an error message saying, «Xcode could not find a valid private-key/certificate pair for this profile in your keychain.»

This error message indicates that your system’s keychain is missing either the public or private key for the certificate you’re using to sign your application.

This often happens when you’re trying to sign and build your application from a different system than the one you originally used to request your code signing certificate. It can also happen if your certificate has expired or has been revoked. Ensure that your app’s provisioning profile contains a valid code signing certificate, and that your system’s Keychain contains that certificate, the private key originally used to generate that certificate, and the WWDR Intermediate Certificate.

For instructions on how to resolve this error, review the Code Signing support page.

What happens to my applications signed with Developer ID if my Apple Developer Program membership expires?

If your membership expires, users can still download, install, and run your applications that are signed with Developer ID. However, once your Developer ID certificate expires, you must be an Apple Developer Program member to get new Developer ID certificates to sign updates and new applications.

Feedback Assistant

Submit bug reports and request enhancements to APIs and developer tools.

Send us feedback

Developer Forums

Ask questions and find answers by Apple engineers and other developers.

Contact Us

Tell us how we can help and we’ll find a solution by phone or email.

Источник