Chunghwa Telecom Certificate Revocation: In-Depth Analysis of Causes, Technical Details, and Impact

by
🌏 閱讀中文版本

Event Overview

On May 30, 2025, Google’s security team announced through their official blog that Chrome 139 and later versions would stop trusting TLS certificates issued by Chunghwa Telecom starting August 1, 2025. This marks Taiwan’s first major certificate trust crisis, affecting over 10,000 websites, including 8,000 government sites and 2,000 enterprise domains.

This distrust decision stems from multiple compliance failures in Chunghwa Telecom’s certificate management over more than a year, ultimately eroding Google’s confidence. This article provides an in-depth analysis of the root causes, technical details, impact scope, and implications for Taiwan’s digital infrastructure.

Three Major Management Failures

1. CAA Record Validation Failure

Problem Description:

Between September 2024 and February 2025, Chunghwa Telecom conducted a large-scale certificate migration from the Government TLS Certification Authority (GTLSCA) to HiPKI OV TLS CA. During this process, they failed to re-check CAA (Certificate Authority Authorization) records, instead directly reusing DCV (Domain Control Validation) data previously validated by GTLSCA to batch-issue new certificates.

What is CAA?

CAA (Certificate Authority Authorization) is a DNS record type that allows domain owners to specify which certificate authorities can issue certificates for their domain. CAs must check the domain’s CAA records before issuing certificates to confirm they are authorized.

How to Check CAA Records:

# Using dig to query CAA records
dig CAA example.com

# Using host command
host -t CAA example.com

# Example output:
# example.com has CAA record 0 issue "letsencrypt.org"
# example.com has CAA record 0 issuewild "letsencrypt.org"

Impact Scale:

  • Period: September 4, 2024 – February 26, 2025
  • Revoked certificates: 11,860
  • Actually installed: Only 24 (for testing)
  • Notification date: March 1, 2025 (Chrome Root Program)

Root Cause:

Since both GTLSCA and HiPKI OV TLS CA were managed by Chunghwa Telecom, the team mistakenly assumed they could share validation data, overlooking that CAA records are specific authorization mechanisms for individual CAs. This violated CA/Browser Forum Baseline Requirements mandating CAA record validation before certificate issuance.

2. Delayed Annual Report Submission

Problem Description:

Chunghwa Telecom’s GTLSCA failed to submit the 2023 CCADB (Common CA Database) self-assessment report within the deadline, even after multiple reminders.

Reminder Timeline:

  • September 2023: First reminder
  • March 2024: Second reminder
  • January 2025: Third reminder
  • Final outcome: Report still incomplete

What is CCADB?

CCADB (Common CA Database) is jointly maintained by Mozilla, Microsoft, Google, and Apple. All trusted CAs must regularly submit self-assessment reports detailing compliance status, audit results, and policy changes.

Why It Matters:

Annual reports are core mechanisms for CA transparency and accountability. Delayed submission indicates:

  • Poor internal process management
  • Insufficient attention to compliance requirements
  • Lack of effective deadline tracking mechanisms

3. Compliance Timeline Delays and Other Violations

EKU (Extended Key Usage) Misconfiguration:

  • Period: Since September 15, 2023 (BR v2.0.0 effective date)
  • Affected certificates: Approximately 6,450
  • Issue: Certificate EKU extensions didn’t comply with requirements
  • Revocation requirement: CA/Browser Forum requires revocation within 5 days
  • Actual situation: Chunghwa Telecom couldn’t complete revocation within deadline

Duplicate SubjectDN Fields:

  • Discovery date: September 2024
  • Affected certificates: 247
  • Issue: Certificates contained two localityName values in SubjectDN

Compliance Procedure Adjustment Delays:

Chunghwa Telecom failed to adjust internal procedures within Chrome’s new policy timeframe. While adjustments were eventually completed, trust had already been damaged.

Google’s Technical Implementation of Distrust

SCT-Based Mechanism

Google adopted an SCT (Signed Certificate Timestamp) based distrust mechanism rather than directly removing root certificates.

Technical Details:

  • Determination basis: SCT timestamp in certificates
  • Cutoff time: July 31, 2025, 23:59:59 UTC
  • Impact scope: Certificates with SCT timestamps after the cutoff will trigger security warnings
  • Effective version: Chrome 139 (August 1, 2025)

Affected Root Certificates:

1. ePKI Root Certification Authority
   O=Chunghwa Telecom Co., Ltd.
   C=TW

2. HiPKI Root CA - G1
   CN=HiPKI Root CA - G1
   O=Chunghwa Telecom Co., Ltd.
   C=TW

Testing and Override Options

Test Command (Chrome 128+):

# Simulate SCT distrust constraint
chrome --test-crs-constraints=$SHA256_HASH:sctnotafter=$EPOCH_TIMESTAMP

# Example:
chrome --test-crs-constraints=
"76E27EC14FDB82C1C0A675B505BE3D29B4EDDBBB5C609BA6FCC17E075B5C14BD:
sctnotafter=1722470399"

Enterprise Override Options:

Enterprises can use GPO (Group Policy Object) or platform-specific trust settings to explicitly trust affected certificates, overriding SCT constraints:

Method 1: Windows GPO
Computer Configuration > Policies > Windows Settings >
Security Settings > Public Key Policies > Certificate Path Validation Settings

Method 2: macOS Keychain
Add certificate to system Keychain and set to "Always Trust"

Method 3: Linux ca-certificates
Copy certificate to /usr/local/share/ca-certificates/ and run update-ca-certificates

Impact Scope and Real-World Cases

Affected Website Statistics

  • Total: Over 10,000 websites
  • Government sites: 8,000+ (central and local agencies, schools)
  • Enterprise sites: 2,000+
  • Special case: Even Chunghwa Telecom’s own websites need certificate replacement

User-Facing Error Messages

Starting August 1, 2025, users visiting websites still using Chunghwa Telecom certificates with Chrome will see:

Your connection is not private

Attackers might be trying to steal your information from
example.com (for example, passwords, messages, or credit cards).

NET::ERR_CERT_AUTHORITY_INVALID

Check If Your Site Is Affected

Method 1: Check Certificate Issuer with OpenSSL

# Check certificate details
openssl s_client -connect example.com:443 -showcerts < /dev/null 2>/dev/null | 
  openssl x509 -noout -text | grep -A 2 "Issuer"

# If output contains "Chunghwa Telecom", the site is affected
# Issuer: O=Chunghwa Telecom Co., Ltd., CN=ePKI Root Certification Authority

Method 2: Check SCT Timestamps

# Check certificate SCT extension
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | 
  openssl x509 -noout -text | grep -A 10 "CT Precertificate SCTs"

# If SCT timestamp is after 2025-07-31, Chrome 139+ will distrust it

Method 3: Online Tools

Subsequent Actions and Timeline

Chunghwa Telecom’s Response

  • Suspension: Complete suspension of TLS certificate issuance from August 1, 2025
  • Existing certificates: Certificates issued before July 31 remain unaffected and valid for one year
  • Recovery target: Aims to regain Chrome’s default trust by March 2026
  • Improvement measures: Strengthen internal processes, enhance staff training, improve compliance tracking systems

Recommendations for Affected Organizations

Immediate Actions (Before July 2025):

  1. Inventory existing certificates
    • List all websites and services using Chunghwa Telecom certificates
    • Check certificate expiration dates and issuers
  2. Choose alternative CAs
    • International options: Let’s Encrypt, DigiCert, Sectigo, GlobalSign
    • Taiwan option: GCA (Government Certification Authority) for government sites
  3. Test replacement procedures
    • Verify new certificates in test environments
    • Confirm application compatibility
  4. Plan migration schedule
    • Prioritize high-traffic websites
    • Schedule maintenance windows for replacement

Long-Term Improvements:

  1. Establish certificate management mechanisms
    • Use certificate management tools (e.g., Certbot, cert-manager)
    • Set up expiration reminders
    • Automate renewal processes
  2. Implement monitoring mechanisms
    • Monitor certificate expiration times
    • Track CA compliance status
    • Set up Certificate Transparency (CT) log monitoring
  3. Diversify CA strategy
    • Avoid single dependency
    • Consider using multiple CAs as backup

Implications for Taiwan’s Digital Infrastructure

1. Compliance Is Not Optional

The international certificate ecosystem is built on strict compliance requirements. Even national-level telecommunications companies face trust revocation when violating regulations. Taiwan’s CA operators must:

  • Establish comprehensive compliance tracking systems
  • Invest in professional staff training
  • Conduct regular internal audits
  • Actively participate in international standard development

2. Vulnerability of Government Digital Services

The impact on 8,000 government websites reveals Taiwan’s government digital services’ high dependency on a single CA. Recommendations:

  • Establish GCA (Government Certification Authority) as backup
  • Develop government website certificate management regulations
  • Regularly practice CA failure scenarios
  • Enhance IT staff awareness of certificate management

3. Professional Threshold of Certificate Management

This incident highlights certificate management complexity:

  • Importance of CAA record checking
  • Data cannot be shared between different CAs
  • Strict compliance report timelines
  • Time-sensitive revocation procedures

Organizations need to:

  • Assign dedicated staff for certificate management
  • Establish Standard Operating Procedures (SOPs)
  • Use automation tools to reduce human error

4. Transparency and Trust Relationship

Certificate Transparency (CT) makes all certificate issuance traceable. Chunghwa Telecom’s issues were discovered precisely because of CT log monitoring. This reminds us:

  • Transparency is the foundation of trust
  • Hiding problems only makes them worse
  • Proactive disclosure and improvement is the right approach

Action Guide for Developers and Enterprises

Checklist

Website Administrators:

# 1. Check current certificate issuer
openssl s_client -connect your-domain.com:443 -showcerts < /dev/null 2>/dev/null | 
  openssl x509 -noout -issuer

# 2. Check certificate expiration date
openssl s_client -connect your-domain.com:443 < /dev/null 2>/dev/null | 
  openssl x509 -noout -dates

# 3. Check SCT timestamps
openssl s_client -connect your-domain.com:443 < /dev/null 2>/dev/null | 
  openssl x509 -noout -text | grep -A 10 "CT Precertificate SCTs"

Application Developers:

  1. SSL Pinning risk assessment
  2. Update trust anchors in applications
    • If your app embeds trusted root certificate lists, release updates
    • Recommend using system trust store instead of custom lists
  3. Test certificate change impact
    • Simulate new certificates in development environments
    • Verify API connections and third-party service integrations

Automation Tool Recommendations

Certificate Management Tools:

# 1. Certbot (Let's Encrypt)
sudo apt install certbot
sudo certbot certonly --webroot -w /var/www/html -d example.com

# 2. acme.sh (supports multiple CAs)
curl https://get.acme.sh | sh
acme.sh --issue -d example.com -w /var/www/html

# 3. cert-manager (Kubernetes)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml

Monitoring Script Example:

#!/bin/bash
# Check certificate expiration and send warnings

DOMAIN="example.com"
DAYS_WARNING=30

# Get certificate expiration date
EXPIRY_DATE=$(openssl s_client -connect $DOMAIN:443 < /dev/null 2>/dev/null | 
  openssl x509 -noout -enddate | cut -d= -f2)

# Convert to timestamp
EXPIRY_TIMESTAMP=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_TIMESTAMP=$(date +%s)
DAYS_REMAINING=$(( ($EXPIRY_TIMESTAMP - $CURRENT_TIMESTAMP) / 86400 ))

# Check if warning needed
if [ $DAYS_REMAINING -lt $DAYS_WARNING ]; then
  echo "Warning: Certificate for $DOMAIN expires in $DAYS_REMAINING days!"
  # Send notification (email, Slack, etc.)
fi

# Check issuer
ISSUER=$(openssl s_client -connect $DOMAIN:443 < /dev/null 2>/dev/null | 
  openssl x509 -noout -issuer)

if echo "$ISSUER" | grep -q "Chunghwa Telecom"; then
  echo "Warning: $DOMAIN uses Chunghwa Telecom certificate - replacement needed urgently!"
fi

Frequently Asked Questions

Q1: Can I still use certificates obtained before July 31?

A: Yes. Certificates issued before July 31 are unaffected and remain valid until expiration (maximum one year). The issue is that after certificate expiration, you cannot obtain new certificates from Chunghwa Telecom and must switch CAs.

Q2: Will other browsers follow Chrome’s decision?

A: Currently, only Google has formally announced Chrome’s distrust decision. Edge (Chromium-based) will likely follow. Firefox and Safari maintain their own root certificate lists; watch for subsequent announcements from Mozilla and Apple. Historical precedent shows major browsers align on CA compliance issues, making follow-through highly probable.

Q3: Are free certificates like Let’s Encrypt sufficient?

A: For most websites, Let’s Encrypt’s DV (Domain Validation) certificates are sufficient. However, paid CAs may be needed for:

  • OV/EV certificates: Display organization name, green address bar (EV)
  • Warranty coverage: Paid CAs typically offer digital certificate insurance
  • Technical support: Paid CAs provide professional customer service
  • Internal policy requirements: Some organizations prohibit free certificates

Q4: How to prevent similar issues in the future?

A: Recommended measures:

  1. Diversified CA strategy: Don’t depend on a single CA, prepare backup plans
  2. Automation: Use Certbot, cert-manager, etc. to auto-renew certificates
  3. Monitoring mechanisms: Set up expiration reminders, track CA compliance status
  4. Regular drills: Practice CA switching procedures at least annually
  5. Document processes: Establish comprehensive certificate management SOPs

Q5: Does this event affect Android/iOS applications?

A: Yes, especially applications implementing SSL Pinning:

  • Using system trust store: Android 7.0+ and iOS will follow OS updates, eventually distrusting Chunghwa Telecom certificates
  • Implementing SSL Pinning: If your app directly pins Chunghwa Telecom certificates or public keys, urgent updates needed
  • Custom trust chains: If your app uses custom root certificate lists, remove Chunghwa Telecom certificates

Developer recommendations:

  • Check if your app implements SSL Pinning
  • If yes, switch to public key pinning and pin server certificate public keys, not CA root certificates
  • Regularly update app trust settings

Conclusion

The Chunghwa Telecom certificate revocation is a critical wake-up call for Taiwan’s digital infrastructure. This crisis highlights:

  1. Importance of compliance management: Certificate ecosystems are built on strict regulations and transparency
  2. Risks of single-point dependency: Government and enterprises shouldn’t over-rely on a single CA
  3. Need for professional talent: Certificate management requires specialized knowledge and continuous learning
  4. Necessity of automation: Manual management is error-prone; automation is the trend
  5. Crisis response capability: Organizations must have rapid response capabilities and procedures

Affected organizations should immediately begin certificate inventory and migration planning, completing replacement before August 2025. Long-term, Taiwan needs a more robust certificate management ecosystem, including government-supported backup CAs, professional talent development, and industry best practice promotion.

This event also reminds all developers and enterprises: digital trust is not guaranteed—it requires continuous effort and investment to maintain.

Related Articles

Related posts:

  1. 中華電信憑證撤銷事件深度分析：前因後果、技術細節與影響
  2. Synergy Between Development and Security: Building Complementary High-Performance Technical Teams
  3. iOS SSL Pinning and Certificate Validation Guide
  4. Complete Guide to Importing SSL/TLS Certificates in AWS

Leave a Comment