Last year Chunghwa Telecom, this year TWCA: what to check before the 6 November deadline

Last year it was Chunghwa Telecom: from Chrome 139, on platforms using the Chrome Root Store, TLS server certificates chaining to two specified roots lost default trust if their earliest SCT fell after 31 July 2025 (UTC). This year TWCA (Taiwan-CA) has announced a certificate replacement. Its previous intermediate CA “must be revoked by 00:00 on November 6, 2026”, customer certificates are being re-signed under a new intermediate with the same key pair, and you are asked to install the full chain. A replacement runbook needs to be ready.

The announced actions differ. Chunghwa was a Chrome Root Program decision, with a cut-off based on whether the earliest SCT fell after 31 July 2025 (UTC); earlier certificates were unaffected by that change. TWCA is a CA replacing its own intermediate, and as of this check the three bugs contained no Mozilla or Chrome decision on these incidents. The work is straightforward: find where TLS terminates, install the new certificate with the full chain before the deadline, then look at what the server sends from outside your network.

The notice leaves gaps. It gives no time zone for 00:00, no list of intermediates or fingerprints, and says nothing on whether subscriber certificates will be revoked or whether the new intermediate has a new key. The same week produced public reports on two other issues: serial number entropy and unauthorised access to an RA server. The public record has not established a causal link between the three, so they are kept apart here. Sources were first checked, and the example run, at 20:44 Taipei time on 2 November 2026, and rechecked at 22:12.

Timeline

29 October 2026, 08:07 UTC: TWCA self-reports Bugzilla 2086949, signs of unauthorised access to an RA server.
29 October, 19:31 UTC: outside researchers open 2087236 on low randomness in CA certificate serial numbers. The report’s own timeline says 30 October; the system record is used here.
31 October: TWCA publishes the SSL renewal notice.
2 November, 00:16 UTC: 2087918 reports a separate entropy problem in subscriber certificate serials. TWCA replies at 04:08 UTC that the full report will be folded into 2087236.
6 November, 00:00 (time zone not stated): deadline for the previous intermediate.
12 November, 19:00 UTC: the date TWCA has committed to for its full incident report.

A few questions from the ops side

Replacing certificates takes scheduling, and scheduling needs a time and a list. The notice happens to give neither. TWCA’s listed shareholders are the Taiwan Stock Exchange, the Taiwan Depository and Clearing Corporation, the Financial Information Service Co. and 網際威信 (HiTRUST). The notice date, 31 October, and the deadline, 6 November, are six calendar days apart. It gives no time zone for 00:00 and lists no intermediates or fingerprints. The Chinese text says 廢止 and the English text says revoked, so operators should plan for revocation. Could the notice add the time zone and the affected intermediates, so operators can actually plan the work?

Those are the visible gaps. How the work was planned inside, and why the notice reads as it does, the public record does not say, and this post will not guess. The full report due on 12 November concerns the serial number incidents; whether it will clarify the renewal notice remains unknown. Operators should replace the chain before the notice’s deadline.

The public records

The renewal notice

The stated reason, in the Chinese text, is adjusting the intermediate certificate profile to meet international requirements, citing CA/Browser Forum rules. Customer certificates are re-signed under the new intermediate with the existing key pair and must be installed with the full chain. The Chinese text says the old intermediate will be 廢止; the English text on the same page says revoked, so plan for revocation. There is no list of intermediates, no fingerprints, nothing on subscriber revocation, browsers or fees. The support line is 02-2370-8886 ext. 9, and SSL sales is 0800-002-666. The notice covers SSL customer certificates only, and nothing here extends it to TWCA’s other products.

Bug 2087236: CA serial numbers

Opened by Prasanth Sundararajan and co-signed by Dr. Angelique Faye Loe. The reporters break the serial down as a 1-byte prefix, the notBefore date, zero padding, a 2-byte counter and 3 random bytes, so at most 24 bits look random. The TLS Baseline Requirements (BR) ask for at least 64 bits of CSPRNG output. They checked 24 CA certificates issued from TWCA’s publicly trusted root keys (2011-06-10 to 2024-09-06). Of the 18 issued after 2016-09-30, the reporters count 11 as within the TLS BR (10 unrevoked at the time of the report, 1 revoked as superseded on 2023-08-17), 2 are the self-signed roots TWCA CYBER Root CA and TWCA Global Root CA G2, and the remaining 5 are not claimed to be in scope.

At the time of the report, six TLS issuing intermediates were unrevoked. Fingerprints are in the crt.sh links inside the bug:

TWCA SSL Certification Authority, signed by CYBER Root, one each on 2023-02-23 and 2024-09-06.
TWCA EVSSL Certification Authority, signed by CYBER Root, one each on 2023-02-23 and 2024-09-06.
TWCA Secure SSL Certification Authority, signed by Global Root, one each on 2023-08-18 and 2023-10-16.

That is the reporters’ list. The notice gives no list of intermediates to be revoked, so the two cannot be matched. The reporters also sampled 1,631 subscriber serials from 29 CRLs and saw no problem; 2087918 later covered subscriber certificates. They write “We have no evidence of key compromise, certificate misuse or any exploitation.” and “A short serial number does not by itself allow forgery with SHA-256 signatures.”, and say BR 4.9.1.2 and 4.9.5 “may apply”. In Comment 3 TWCA acknowledges the report, says it is investigating, and commits to a full report by 19:00 UTC on 12 November 2026. Root cause and the other sections still read “For TWCA to complete”.

Bug 2087918: subscriber serial numbers

Daniel C looked at about 1,600 certificates from 2025 CT logs plus a few recent unexpired ones. Going by TWCA’s earlier description, the last 8 bytes of the serial should hold 64 bits of HSM CSPRNG output, yet the top bit was always 0 and the top byte stayed between 0x00 and 0x7F. The issuing CAs seen were TWCA EVSSL Certification Authority, TWCA Global EVSSL Certification Authority, TWCA Secure SSL Certification Authority and TWCA SSL Certification Authority. The number affected is unknown. TWCA replied “Both incidents involve insufficient serial number entropy.” and is folding the report into 2087236.

Bug 2086949: the RA server

Self-reported by TWCA, status ASSIGNED. Security monitoring picked up signs of unauthorised access to an RA server, which has been isolated while the investigation continues. The report says “No certificate mis-issuance has been identified to date.” Only the preliminary report exists. Scope, cause, and any link to the serial number issue are all unknown.

As of 22:12, none of the three bugs carries a decision on these incidents from the Mozilla or Chrome root programmes, and no related distrust announcement turned up. That is what the sources showed at the time, not a promise that trust will hold.

Why serial numbers need to be random

BR v2.3.1 requires serialNumber to be a non-sequential number greater than zero and less than 2^159, containing at least 64 bits of CSPRNG output. Ballot 164 in 2016 gave the reason: random bits make hash collision attacks harder. The 2008 rogue CA research predicted the serial number and validity period, then used an MD5 collision. That is background only, not evidence that the same attack occurred in this incident.

Length and randomness are separate questions. The CA serials in 2087236 are like a lottery ticket that prints the draw date first and only rolls a few digits at the end: a long string, with just the last 3 bytes actually drawn. The subscriber sample in 2087918 has the top bit of the last 8 bytes fixed at 0, which caps the possible values at 2^63, too few to count as 64 bits of CSPRNG output. Both are low entropy, but the gaps are very different in size.

Low entropy breaks the BR. It does not mean a private key leaked, a certificate was misused, or anyone can produce a fake that passes SHA-256 signature checks. The reporters found no sign of exploitation, and TWCA says no mis-issuance has been found in the RA case. Those sentences belong to different documents, and you can’t stitch them into “so it’s fine” or “so it was exploited”.

Four ways a connection fails

Case	What happens	What this check shows
Expiry	The current time is past notAfter	The tested leaf runs to 2027-03-06, the intermediate to 2030-08-23
Revocation	The client finds a revoked certificate on the path and rejects it	The English notice says the old intermediate must be revoked; nothing on subscriber certificates
Root distrust	A root programme drops a root, so the path loses its trust anchor	No Mozilla or Chrome decision on these incidents in the three bugs
Missing chain	The server leaves out the intermediate, so the client cannot build a path	The notice asks for the full chain; the certificate itself can still be valid

Think of the intermediate as a letter of introduction. The client knows the organisation at the root, the leaf certificate is a staff badge, and the intermediate vouches for the link. Forget the letter and reception cannot match the badge. An expired letter, a withdrawn letter and an organisation struck off the list are the other three cases, and each needs a different fix.

Once an intermediate is revoked, a client that obtains that revocation status will reject a path through it, even if the leaf itself is unrevoked and in date. A notAfter in 2027 or 2030 therefore proves nothing about the old chain after the deadline. BR 4.9.1.2 gives a CA seven days to revoke an intermediate once it learns the intermediate was issued out of compliance, among other reasons. For subscriber certificates, 4.9.1.1 item 12 says SHOULD within 24 hours and MUST within 5 days, with an exception for short-lived certificates. Those are the rules. TWCA has not said what it will do with subscriber certificates, so no deadline is worked out here for them. Nor is there any reason to change users’ browser trust settings.

Replacing and checking

The notice only says that customer certificates are re-signed under the new intermediate, the key pair stays, you install what you receive, and you include the full chain. Because the new intermediate’s name and key are not given, a changed issuer name alone is not proof. Compare the new certificate and its fingerprint instead. What follows is general ops practice, with verification left on:

List the domains and services that use these TWCA SSL certificates, and where TLS terminates: load balancer, CDN, Ingress, IIS or the application itself.
In Nginx, point ssl_certificate at a fullchain file with the leaf first and the intermediate after it. In IIS, import the intermediate into the Local Computer “Intermediate Certification Authorities” store. In a Java keystore, update the chain on the private key entry.
Replace it where TLS actually terminates. If a CDN or load balancer terminates TLS in front, changing only the origin leaves the public chain as it was.
Check the chain the server sends from outside, not the file on disk. A CT log search (crt.sh, for example) shows whether the new certificate or precertificate was logged. It does not show that it is deployed.

chain.sh only lists each certificate the server sends. Its output says nothing about whether chain validation, hostname checks or revocation checks passed. It writes certN.pem to the current directory and deletes cert*.pem at the end, so run it in an empty directory. The command and output below come from a single connection to www.twca.com.tw at 20:44 Taipei time on 2 November 2026, on macOS with LibreSSL 3.3.6, and are left exactly as captured.

#!/bin/sh
# 列出伺服器實際送出的每張憑證：subject、issuer、SHA-256 指紋、到期日
host="$1"
echo | openssl s_client -connect "$host:443" -servername "$host" -showcerts 2>/dev/null |
  awk '/BEGIN CERTIFICATE/{n++; f="cert" n ".pem"} f{print > f} /END CERTIFICATE/{f=""}'
for f in cert*.pem; do
  echo "== $f"
  openssl x509 -in "$f" -noout -subject -issuer -enddate
  openssl x509 -in "$f" -noout -fingerprint -sha256
done
rm -f cert*.pem

== cert1.pem
subject= /businessCategory=Private Organization/jurisdictionCountryName=TW/jurisdictionStateOrProvinceName=Taiwan/jurisdictionLocalityName=Taipei/serialNumber=70759028/C=TW/ST=Taiwan/L=Taipei/postalCode=100/street=10F.,NO.85,Yanping S. Rd.,Taipei City 100,Taiwan (R.O.C)/O=TAIWAN-CA INC./CN=www.twca.com.tw
issuer= /C=TW/O=TAIWAN-CA/OU=Global EVSSL Sub-CA/CN=TWCA Global EVSSL Certification Authority
notAfter=Mar  6 15:59:59 2027 GMT
SHA256 Fingerprint=53:D5:48:E7:AD:6E:B8:E5:DD:90:CE:34:45:33:06:8C:8F:E3:D2:9E:D2:4B:B2:E0:DA:51:36:DC:45:DF:8B:02
== cert2.pem
subject= /C=TW/O=TAIWAN-CA/OU=Global EVSSL Sub-CA/CN=TWCA Global EVSSL Certification Authority
issuer= /C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Global Root CA
notAfter=Aug 23 15:59:59 2030 GMT
SHA256 Fingerprint=49:69:5A:5F:0F:7E:F6:ED:F6:98:19:3D:99:ED:48:BA:AD:E2:0E:A4:57:40:3C:11:CE:AD:49:2C:45:86:65:DA
== cert3.pem
subject= /C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Global Root CA
issuer= /C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Root Certification Authority
notAfter=Oct 28 15:59:59 2030 GMT
SHA256 Fingerprint=8A:D4:7F:6D:70:A4:4F:A8:0A:F0:F9:31:12:5F:FE:3A:76:87:6F:FA:D2:19:A4:D4:0A:13:C0:38:DC:85:E6:9E

Three certificates came back: www.twca.com.tw, TWCA Global EVSSL Certification Authority, and TWCA Global Root CA. The third is issued by TWCA Root Certification Authority, which makes it a cross-certificate; having Root in its name does not make it the trust anchor here. All three notAfter times are 15:59:59 GMT, which is 23:59:59 the same day in Taipei. The same connection also recorded the leaf serial 47EA000000125CE071DBC24EAA7BA455 and notBefore 2026-02-26, which the script does not print. The cert2 fingerprint matches TWCA Global EVSSL Certification Authority in the 2087236 appendix. Whether it is one of the intermediates due on 6 November cannot be checked, because the notice has no list. It is a single sample, meant as a demonstration, and can neither confirm nor refute 2087918.

Pinning and other clients

If an app pins, first find out what it pins: intermediate, root or leaf, whole certificate or public key. An app pinning the old intermediate’s key will reject a new chain that contains no matching key, even when browsers accept it. With a root key pin, confirm that the new path still goes through that key. A leaf key pin should usually still match, since the key pair is unchanged, but normal certificate validation must still pass; a pin on the whole leaf certificate has to be updated after re-signing. Java, older Android and embedded truststores do not always share the desktop browsers’ trust anchors. A working browser proves nothing about them, so test each one.

Still unknown

Which intermediates will be revoked. The six in 2087236 are the reporters’ list; the notice names none.
The time zone for 00:00. Read as Taipei time it is 16:00 UTC on 5 November; read as UTC it is 08:00 on 6 November in Taipei. For scheduling, take the earlier one, 00:00 on 6 November Taipei time.
Whether and when subscriber certificates are revoked; the new intermediate’s name, fingerprint and key; whether there is a fee.
The scope and cause of the RA incident, and whether it has anything to do with the serial number issue.
Worth following: the full report due before 19:00 UTC on 12 November and whether Root cause gets filled in; any Mozilla or Chrome action on these incidents in the three bugs; whether TWCA adds the list, the time zone and the new fingerprints.

Notes

The previous intermediate must be revoked by 00:00 on 6 November 2026; time zone and list not given. Customer certificates keep their key pair and need the full chain installed.
The renewal notice, the serial entropy reports and the RA access report concern separate issues, with no causal link established in the public record so far.
CA serials show at most 24 random-looking bits and the subscriber sample at most 63. That breaks the BR, but does not establish key compromise or show that forgery is possible.
Expiry, revocation, root distrust and a missing chain are four different failures. Once an intermediate is revoked, a distant notAfter does not guarantee that a path through it will work.
Check the chain the server sends from outside, and test pinned apps, Java, older Android and embedded truststores separately.