CY24 Ant Group Website New Root Certificate Upgrade Instructions
1. Background
The Ant Group website employs HTTPS to ensure secure communication. When invoking system services or APIs provided by Ant Group, the software or system uses root certificates from Certificate Authorities (CAs) to verify the authenticity of the Ant Group website server's identity.
Due to Mozilla's update to its root certificate trust policy, which mandates that the trusted root certificates of all global CAs be replaced at least every 15 years, any root certificates exceeding this duration will gradually lose Mozilla's trust. Consequently, DigiCert will progressively phase out its old root system (G1) for issuing TLS/SSL certificates and transition to its new root system (G2).
Currently, the Ant Group website server's certificate is issued by the authoritative electronic certification agency DigiCert, with "DigiCert Global Root CA" as the root CA. Starting from August 2024, Ant Group plans to gradually enable new server certificates issued by DigiCert, using "DigiCert Global Root G2" as the root CA.
To enhance compatibility during the deployment of new certificates, we will add a cross-root certification between DigiCert Global Root CA and DigiCert Global Root G2 on our services to ensure a smooth upgrade in 2024. Therefore, as long as the client's trusted root certificate store includes either DigiCert Global Root G2 or DigiCert Global Root CA (with Baltimore CyberTrust Root no longer being supported), it will be compatible with the new server certificates. Most modern operating systems and newer execution environments have already integrated these two root CA certificates into their default trusted root certificate stores, and most systems will not require special configuration adjustments for compatibility. If the system has not been upgraded on time, please follow the provided documentation to perform checks and necessary actions.
By 2026, the client's trusted root certificate store must include DigiCert Global Root G2. We strongly recommend verifying that the client's root certificate store contains DigiCert Global Root G2.
2. New and Old Root Certificate Information
The following table lists the basic information for DigiCert's three root certificates, along with their compatibility with common operating systems and execution environments:
Table 1: Information for New and Old Server Root CA Certificates
Root Certificate Name | Root Certificate File | Serial Number | Validity Period | Mozilla Trust End Date | Windows | Mac | Java | Android | iOS | Firefox | Notes |
DigiCert Global Root G2 | 33af1e6a711a9a0bb2864b11d09fae5 | August 1, 2013 – January 15, 2038 | April 15, 2029 | XP SP3+ | OS X 10.10+ | 1.8.0_131+ | 5.0+ | iOS 7.0+ | 32+ | This is the root CA for the new certificates. If there are compatibility issues, add this root certificate to the trust store of the execution environment. | |
DigiCert Global Root CA | 83be056904246b1a1756ac95991c74a | November 10, 2006 – November 10, 2031 | April 15, 2026 | XP SP3+ | OS X 10.6+ | 1.4.2_17+ | 1.1+ | iOS 4.0+ | 2.0+ | This is the compatibility root for the new certificates. | |
Baltimore CyberTrust Root | 20000b9 | May 13, 2000 – May 13, 2025 | April 15, 2025 | XP+ | - | 1.4.2+ | 2.0+ | iOS 5+ | 1.0+ | This will no longer be supported in the future. |
Notes:
- macOS: According to Apple's Lists of available trusted root certificates in macOS.
- Linux: The location for storing trusted root certificates in Linux systems varies by distribution. Most Linux distributions use the directory /etc/ssl/certs/ or the file /etc/pki/tls/certs/ca-bundle.crt for the system's trusted root certificate store.
- This information is primarily from DigiCert's officially published compatibility list:
Compatibility of DigiCert Trusted Root Certificates
3. Actions Required
You must ensure that your business systems interacting with Ant Group's systems are compatible with the new server certificates. Specifically:
- If compatibility is confirmed, no further action is needed.
- If incompatibility is found, necessary corrections must be made to your systems.
We recommend completing the validation as described in the How to Validate section as soon as possible. If the system is incompatible, modifications should be completed by August 7th, 2024. Failure to do so will result in disruption of HTTPS communication between your business system and Ant Group's services, affecting normal operations.
If you encounter any issues during validation and corrections, please contact Ant Group technical support using the contact information provided in this document.
4. How to Validate
You can verify your system's compatibility with the new server certificates using the test domain provided by Alipay. It is strongly recommended to perform the same test in the production environment to ensure support for the new certificate.
- Compatibility Check: If your system can successfully obtain a response from Ant Group's system, it indicates compatibility. If not, it is likely incompatible.
- Incompatibility Check: If your system is incompatible, consult your system's TLS/SSL library documentation to verify that the root CA of the new server certificate is included in the truststore of the execution environment. Refer to Chapter 6 of this document for possible correction methods. Revalidate after completing the necessary steps.
Validation Environment with Only DigiCert Global Root G2
To help verify if your environment supports the DigiCert Global Root G2 root certificate, we have prepared a separate domain for validation. This new domain will only contain the DigiCert Global Root G2 root certificate.
Domain | Public IP | Activation Date |
47.235.24.194 47.235.24.195 47.235.21.35 47.235.21.45 | June 15, 2024 | |
Notes:
- If your IDC egress has whitelist configurations, please ensure that the public IP corresponding to the test domain is included in your whitelist.
- The same domain can be used in the production validation environment, which supports network connectivity testing but not business interface functionality.
- Your system should be compatible with both the new and old server certificates.
5. Frequently Asked Questions (FAQs)
Q1: What is a server certificate?
A server certificate, also known as an SSL certificate or domain certificate, is issued by an authoritative institution to authenticate a website. It enables a secure transmission channel between the client and the website via TLS/SSL protocols, with HTTPS being the most common application-layer protocol based on TLS/SSL.
Q2: What is a root certificate?
A root certificate identifies an authoritative institution. It is a digital certificate signed by the institution's private key. Root certificates need to be distributed via tamper-proof channels. Browsers, operating systems, and TLS/SSL development libraries typically come with pre-installed root certificates from trusted authorities.
Q3: How do I confirm compatibility with the new certificate?
We recommend following the validation methods described in Chapter 4 for verification. If you are proficient in TLS/SSL technology and applications, you may also check the relevant system code and configuration to determine compatibility.
Q4: When should the new root CA certificates be installed?
You must install new root CA certificates in your system by August 7th, 2024, since we will begin the gradual application of the new certificates in the production environment to test partners' system readiness.
Q5: What should be noted during the correction process?
The installation process involves adding the new root CA certificate while ensuring compatibility with the old certificates. This should be completed before August 7th, 2024, when the gradual deployment of the new certificates begins. During this period, some servers will use the new certificates while others will continue to use the old ones.
Q6: Which websites/domains are affected by this upgrade?
The server certificate upgrade will cover certificates applicable to multiple domains via the X.509 V3 Subject Alternative Name (SAN) extension. The three affected certificates have Subject Common Names (CN) as .alipay.com, render.alipay.com, .alipayobjects.com. You can verify the domains using the openssl
command line tool:
openssl s_client -connect real_domain_name:443 -servername real_domain_name -showcerts
For example, verify www.alipay.com:
Q7: When should the validation be completed? What if it isn't done on time?
Validation should be completed by August 7th, 2024. If your system is compatible with the new certificates, business operations will remain unaffected. If not, it may disrupt interactions with Ant Group's systems.
Q8: When should the system modification be completed if we fail to validate on time?
If your system is incompatible, modifications should be made by August 7th, 2024.
6. Reference Correction Methods
6.1 JAVA
6.1.1 Incompatibility Symptoms
If your system returns errors such as javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed...
, it indicates incompatibility.
6.1.2 Correction Methods
For Java programs, trusted root certificates (trustStore) might be located in the Java Runtime Environment (JRE) distribution's cacerts
file or a self-managed trustStore.
To check cacerts
content:
- Export its contents to a readable format:
keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass YourPassword > cacerts.txt
- Search for trusted certificates of specific subjects in
cacerts.txt
. If not found, add root CA certificates using:
keytool -keystore $JAVA_HOME$/lib/security/cacerts -importcert -alias CAFriendlyName -file rootca-cert.pem
For systems relying on a self-managed trustStore, two approaches are available:
- Switch to using the default
cacerts
. - Add new root CA certificates directly to the existing trustStore:
keytool -keystore your_trust_store.jks -importcert -alias CAFriendlyName -file rootca-cert.pem
Refer to Keytool for detailed information.
6.2 PHP
6.2.2 Incompatibility Symptoms
Errors such as cURL error 60: SSL certificate: unable to get local issuer certificate
or CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates
indicate incompatibility.
6.2.3 Correction Methods
Depending on the system setup, update OpenSSL's trust store to include the new root CA certificate:
OS Type | Trust Store Location | Command to Add Root CA Certificate |
Linux | /etc/ssl/certs/ | cp rootca-cert.pem /etc/ssl/certs/ |
Linux | /etc/pki/tls/certs/ | cat rootca-cert.pem >> /etc/pki/tls/certs/ca-bundle.crt |
Unix | /System/Library/OpenSSL/ | cp rootca-cert.pem /System/Library/OpenSSL/ |
For PHP applications using custom root CA certificates:
curl_setopt($curl, CURLOPT_CAINFO, "./rootca.pem");
Add the new root CA certificate:
cat rootca-cert.pem >> ./rootca.pem
6.3 .NET
6.3.1 Incompatibility Symptoms
Errors such as The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
indicate incompatibility.
6.3.2 Correction Methods
Download and import the new root CA certificate into the Windows Trusted Root Certification Authorities.
6.4 Python
6.4.2 Incompatibility Symptoms
Errors such as SSL: CERTIFICATE_VERIFY_FAILED
indicate incompatibility.
6.4.3 Correction Methods
By default, Python uses the SSL module's trust store. Update the trust store or use custom certificates:
# ssl.create_default_context(purpose=Purpose.SERVER_AUTH, cafile=None, capath=None, cadata=None)
context = ssl.create_default_context()
urllib.urlopen("https://site.sample.com", context=context)
Refer to Python's SSL documentation for details.
7. Special Reminders
- Avoid using pre-set Ant Group server certificates for HTTPS connections. Instead, use the X.509 certificate chain verification method.
- Starting from August 7th, we will deploy the new certificates in phases to test system compatibility. Failures may occur during this period; retries usually resolve issues.
8. Contact Us
For any questions about this upgrade or difficulties during validation or correction, please contact the Ant Group Technical Support Team at connect_support@service.alipay.com.