Sources checked on October 22, 2026, Beijing time. Audience: individual users, website operators, developers, and system administrators.
Serious weaknesses made a group of eMudhra/emSign intermediate CA private keys recoverable. This affects clients that use the public certificate system to authenticate websites, APIs, and software. Public trust spans major operating systems, but the set of compromised keys and the potential client impact are different scopes. 15
The main text uses square brackets to number corresponding sources, and all external reference links are listed in the appendix. The version listed is the version baseline confirmed to contain the fix for this incident as of the verification date. When deploying, priority is given to the updated stable version in the same supported branch.
TL;DR
Eight intermediate CA private keys are confirmed compromised. Current reports do not establish that root private keys or HTTPS cryptography in general have been broken. Updates span much of the public trust ecosystem; residual risk depends on the actual application.15
- Individual users: update browsers, operating systems, and security components. On Android, also update Google Play services. Use Firefox Android 158.0.2 or later. 12
- Servers: update the distribution’s
ca-certificates/NSS packages and check application-bundled trust stores. Updating only the host is insufficient. 7810 - Development environments: update Node 24 to 24.22.1 or a newer release in that branch as applicable. In Python environments, update to at least pip 26.2.2, certifi 2026.10.19, and uv 0.13.4. Obtain fixed Go binaries or rebuild them; update Java according to its vendor’s advisory. 12–15
- Activate the updates: restart affected services and rebuild and redeploy containers. For Cloudflare Tunnel, update cloudflared to 2026.10.2 or later. 7
- Website certificates: replace an affected chain if it contains a revoked or blocked intermediate CA, or relies on a distrusted root. Reissuing a certificate does not replace updating client trust stores. 158
- Verification: test the actual TLS path of each application. Distinguish certificate rejection from timeouts and DNS failures. Keep certificate verification enabled; do not use
-kor skip verification to suppress errors. 7
1 Facts and causes of the incident
confirmed facts
Mozilla and Google have confirmed defects in eight eMudhra intermediate CA private keys. The researcher supplied proof of private-key control; Mozilla independently recovered the keys and reproduced the issue. Six intermediate CAs serve TLS and two serve code signing. 25
The defect lies in the generated keys: these intermediate CAs use the P-384 curve, but their private keys are integers below 256. This is far from securely selecting keys at random from the intended large range. Recovering these weak keys does not demonstrate that properly generated P-384 keys can be broken. 2
The “certificate is cracked” here should be accurately understood as “the corresponding private key can be recovered”. The certificate and the public key in it are inherently public; what really needs to be kept secret is the private key that can generate a valid signature.
Key-generation process issues still under investigation
An initial description of eMudhra traces the problem to a key generation ceremony in April 2025. The explanation involves a key encapsulation and decapsulation step: in addition to the original strong key, another set of weak keys appears, and the weak keys are subsequently used for certificate application and issuance. The company still said the exact root cause has not been conclusively determined. 6
Therefore, what can be determined is that these keys are seriously weak and have been compromised; the failure cannot be further described as a certain hardware random number source of HSM has been proved to be defective, nor can it be described as a general cryptographic breakthrough of RSA, ECC or TLS.
What does root certificate distrust mean?
The browser or operating system can directly block the certificate or public key of the affected intermediate CA, or it can remove the root trust leading to them. The latter measure will also reject some legitimate certificates under the same root.
Google has scheduled the removal of emSign ECC Root CA - G3 to protect users of the Chrome root store who do not receive updates from CRLSet. The root store removal is expected to be pushed during the corresponding period from October 27th to 28th, Beijing time; the original time of Google is the morning of October 27th, US Pacific Daylight Time. This plan is separate from the emergency public key blocking that has been deployed previously. 1
Distrusting a root is a response measure; it does not itself prove that the root private key was compromised.
2 Why the potential impact spans the public trust ecosystem
Compromised keys and affected trust paths
| Judgment object | The scope of this incident |
|---|---|
| Problematic key identified | 8 intermediate CA private keys for eMudhra |
| Platforms that may require action | Public root store, browser, operating system, language runtime, software package and container ecosystem |
| Possibly impersonated identity TLS | Websites or services visited by clients that still accept the associated forged certificate chain |
| Does it mean that all devices have been compromised? | No; trust conditions, attacker network location, and other verification strategies determine exploitability |
| Does it mean that all legal certificates are invalid? | No; the associated invalidation depends on which roots or certificate chains the client has untrusted. |
Red Hat explicitly limits exploitation to conditions where the client still accepts the relevant chain, the attacker possesses the compromised private key, and is able to intercept the connection in the network. Risk coverage is not to be confused with the number of attacks that have occurred. 10
Websites using other CA may also be impersonated
Suppose a website actually uses the Let’s Encrypt certificate, and the visitor’s client trusts multiple public CA at the same time. An attacker could try to use the compromised intermediate CA to create another certificate for the same domain name. Clients usually do not require in advance that the domain name can only use Let’s Encrypt; if the fake chain is still accepted, which CA the website actually uses is not enough to rule out such attacks. 8
This mechanism explains: Replacing another CA certificate that was originally normal will not automatically repair the client’s trust in the compromised CA. What really needs to be cut off is the path for clients to accept fake identities.
The three effects need to be dealt with separately
Identity impersonation risk: Clients that have not blocked the relevant chain may accept the identity forged by the attacker, causing sensitive requests to be sent to fake services.
Legitimate service availability risk: removing root trust can cause certificate errors for otherwise legitimate websites, which may need migration to another accepted chain.
Deployment coverage risk: the operating system may be fixed while an application-bundled trust store, virtual environment, old container image, or compiled program retains the old validation behavior.
These three scopes are not identical. Cloudflare’s response covers remote identity validation, shared trust stores, base images, and individual applications, illustrating why the latter two tasks must be handled separately. 7
3 Affected CA and certificate providers
Provider and Impact Type
| provider or system | Role in this incident | Boundaries that need to be distinguished |
|---|---|---|
| eMudhra／emSign | The intermediate CA private key is compromised directly. | You cannot write all eMudhra roots and all certificates as cracked |
| Sectigo related cross-signature chain | A cross-certificate was issued for the same batch of affected public keys, forming another trust path. | The corresponding cross certificate or public key needs to be blocked; the Sectigo root private key has not been proven to be compromised. |
| Relevant certificate levels for Internet2/InCommon | Some legitimate certificates rely on the emSign ECC root to be removed, involving migration | It is a collateral impact of root distrust and cannot be counted as the middle of those 8 weak keys CA |
| Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign, etc. | Not listed as the party whose private key was compromised in this report | Legitimate certificates are not uniformly invalidated; vulnerable clients may still accept fake certificates impersonating the websites they serve |
| CDN, cloud platform, certificate dealer | Possibly provide relevant certificates or use a public truststore when connecting to the origin and API | To check the actual certificate chain and validator, don’t just look at the platform or product name |
Mozilla’s notice documents the compromised keys and Sectigo cross-signatures. Google’s public incident discussion addresses migration of legitimate Internet2/InCommon hierarchies. 25 Cloudflare’s fixes address service and client trust; they do not indicate compromise of Cloudflare’s own CA private keys. 7
TLS certificate chain and cross-signature
The following relationship only describes the TLS related paths this time. It does not include code signing paths, nor does it mean that these paths are still trusted on all platforms. 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ Affected TLS Intermediate CA public key → Forged certificate for target domainAAA Certificate Services→ Affected TLS Intermediate CA public key → Forged certificate for target domain
emSign Root TLS CA - G3 is one direct issuer of the affected TLS intermediates and can itself be a trust anchor in some stores. emSign ECC Root CA - G3 provides another cross-signing layer. Sectigo’s AAA Certificate Services creates an additional path to the same intermediate CA public keys. 17
Therefore, there are two different granularities when repairing:
- Block the exact intermediate CA or public key: this can preserve other legitimate hierarchies under the same root, where the validator supports that mechanism.
- Remove root trust: this can protect clients without intermediate CA blocking capabilities, but may affect compatibility. All other paths that the client accepts must also be covered. 5
“Delete all Sectigo/eMudhra roots” should not be taken as an indiscriminate general step, nor should just deleting a certificate with a similar name mean that all paths are closed.
4 Operating system and browser coverage
Main platform
| Platform | Known disposition | Scope that should be checked when using |
|---|---|---|
| Windows and Windows Server | Microsoft Distribution Blocked via Automatic Certificate Trust List Update | Whether the device received the update; standalone CA bundle does not necessarily use the verification path of Windows |
| macOS, iOS, iPadOS, etc. Apple platform | The incident coordinator confirmed that Apple has deployed the relevant blockade | Every older version and third-party app is not guaranteed to receive the same coverage |
| Android | Google distributes equivalent blocks through the Google Play service | ROM without Google Play service should be verified according to the manufacturer’s announcement; use the built-in verifier for additional verification |
| Ubuntu | System certificate bundle fixes have been provided, including multiple current and old version branches | The old version of ESM supports conditions, container internal certificate package and application built-in library |
| Debian and Devuan | Debian recorded ca-certificates fixed | You must check the actual branch used and the installed package, and you cannot copy the version number of another branch. |
| RHEL and derivatives | The official list is RHEL 6, 7, 8, 9, 10, and covers related products and images that may be affected | As of this check, the announcement has not yet listed a complete list of fixes and errata; “Update not found” cannot be considered unaffected |
| Fedora, Arch, Gentoo, Alpine, etc. | The event maintainer has compiled corresponding repair records | Independently confirmed by release, version branch and image |
| FreeBSD | Officially lists all supported versions and provides system trust store repairs | After the update, restart the relevant daemon process according to the announcement; check the independent application trust store separately. |
For a summary of Windows, Apple and releases, see 4; for Android, see 1; for Ubuntu, Debian, RHEL, and FreeBSD The issuer records are shown in 8–11 respectively.
Systems that are no longer supported, offline devices, NAS, routers, and other embedded environments need to confirm whether they still trust the relevant chain and whether they have channels to receive revocation or software updates. The platform name itself is not a substitute for checking actual verification behavior.
Browser protection is different from operating system protection
Chrome uses CRLSet to distribute emergency blocks; Firefox uses mechanisms such as OneCRL. Firefox has also been released with blocking information to provide additional protection for configurations that do not properly receive remote settings. 13
Some configurations of Firefox Android had not correctly applied the updated list on startup, which Mozilla has stated to be fixed by 158.0.2. Therefore, the status of early 158.0.1 cannot be expanded to include all Android Firefox configurations protected. 2
Measures have been taken for system verification of Apple and Windows, but it does not mean that all command line programs on the same machine will undergo system verification. The event maintainer specifically reminded that some macOS built-in tools use independent certificate files; the actual TLS backend and CA source should be recorded when checking. 4
Protective Boundaries for Certificate Transparency
Google confirmed that before it implemented the block, the six TLS intermediate CA did not issue the TLS certificate that entered the CT log. Therefore, Chrome clients that enforce CT have additional protection. This fact does not rule out the possibility that other clients not executing CT have accepted undocumented certificates. 15
“It turns out that it can be linked to the trusted root”, “potential exploitation conditions exist” and “an attack has occurred” are three different judgments and should not be replaced by each other.
5 Development environment and runtime repair baseline
The following is a baseline of confirmed fixes and is not a requirement to pin these releases long-term. Distros may fix older version numbers by moving back patches, and their security advisories should also be reviewed.
| components | Confirmed version or update method | Deployment considerations |
|---|---|---|
| Node.js 24 | 24.22.1 or update the stable version of the same branch | Contains root repository updates and rejection of blocked public keychains; check the Node path actually used by the service and restart |
| Python certifi | 2026.10.19 or newer version | Check each actual running environment; you cannot update only one package under global Python |
| pip | 26.2.2 or newer version | Separately update pip in the old virtual environment and review the version after the new environment is created |
| uv | 0.13.4 or newer version | Update a copy of the tool as it was actually installed |
| Go | 1.27.3 or 1.26.10, the updated version of the corresponding branch is also available | Rebuild and deploy the relevant programs after updating the tool chain, or obtain the vendor’s repair binary |
| Oracle JDK | Critical patches for corresponding supported version lines | Different JDK publishers follow their own announcements; there is no single version number that applies to all Java releases |
| Cloudflare Tunnel | cloudflared 2026.10.2 or newer version | Update running services; container deployment requires replacing the image and redeploying |
| Cloudflare One／WARP | The fixed client version corresponding to the platform or the updated stable version | Client-side and server-side measures are confirmed separately. For specific platform versions, see appendix 7 |
The original instructions for Node, Python, Go, Oracle and Cloudflare are respectively available in 13, 12, 14, 15, 7.
Python independent certificate database problem
Python officials pointed out that the old pip will use a combination of system trust and built-in certifi. Simply modifying the system certificate store or adding a CA file to pip cannot reliably exclude its built-in old trust. Therefore, PIP_CERT, REQUESTS_CA_BUNDLE or --cert cannot be used as a universal repair replacement for the older pip. 12
Check existing virtual environments after updating. Also check the pip version actually installed in newly created environments so that older bootstrap components do not reintroduce vulnerable tools. For the initial upgrade, follow the download sources and SHA-256 verification steps in Python’s advisory before updating other packages. 12
Go and other compiled programs
The fix for Go changed the validation logic for crypto/x509. 14 From the perspective of the deployment mechanism, updating the compiler on the development machine will not rewrite the already deployed binary. To obtain the new code layer blocking, the application should be rebuilt and replaced, or an updated version provided by the vendor should be used. Whether an older program can also benefit from system root updates depends on the actual verification path it uses.
Containers and packaged applications
The system certificate package, application dependencies and runtime in the container are usually determined by the image content. Host update is not equal to image content update; the basic image and dependencies need to be updated, and the actual running instance needs to be rebuilt, deployed, and checked. Packaged applications and desktop programs that come with their own runtime should also be updated according to vendor release channels. 710
6 Repair implementation instructions
Determine the inspection object first
It is recommended to record the following information for the services that need to be protected, and then select the corresponding repair path. This is a deployment checklist and does not require all components to be present on every system.
| Project | What needs to be recorded |
|---|---|
| Applications and uses | Browser, payment API client, email sending service, download tool, reverse proxy, etc. |
| operating position | Host, container, virtual machine, desktop application or mobile device |
| Verify implementation | Operating system validator, OpenSSL, Node, Python library, Java or application custom implementation |
| trusted source | System CA package, certifi, JDK trust store, built-in CA bundle or enterprise configuration |
| Repair status | Installed version, patch source, whether to restart or redeploy |
| Acceptance results | Whether the affected chain is rejected, whether the normal business connection is successful, and the check time |
The developer guide for Cloudflare specifically states that SDK may delegate verification to other components; only updating the top-level SDK does not necessarily change the real trust policy. 7
Operating systems and browsers
Windows: enable and verify automatic certificate trust list updates. Distribute updates through established management policies. Offline devices or devices with automatic updates disabled need the block applied through an appropriate management process. Check programs that do not use Windows system validation separately. 4
Apple Platform: Complete system, security component and application updates. For the development tools on macOS, also check its TLS backend, certificate files and installation sources. It cannot be judged that the entire machine has been repaired just because Safari has rejected the test chain. 4
Android: update Google Play services on devices that have it. Google states that restarting a device can trigger an immediate update. For devices without those services, follow the vendor or ROM advisory; Google’s coverage statement does not automatically apply to every Android device. 1
Ubuntu/Debian: update certificate packages from supported repositories and check the advisory for the installed distribution. For example, an APT-based system can use:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesRelevant updates for Ubuntu 22.04, 24.04, 26.04, and 26.10 are standard support; earlier versions should check ESM support and warehouse status. After the command ends successfully, you should still compare the fix pack version in the bulletin. 89
RHEL and related products: Check the certificate package and security errata by product channel. Version checking can be done using:
rpm -q ca-certificatesUse the supported DNF/YUM update mechanism to obtain vendor patches; if the channel has not yet provided a fix, do not consider “no updateable package” as safe. When it is necessary to temporarily remove root trust, adopt measures clearly listed by the manufacturer and evaluate the compatibility of legitimate business certificates. 10
FreeBSD: update the relevant system branch as directed by the official advisory, then restart daemons using the affected OpenSSL trust configuration or reboot the system. 11
Applications and images
After completing the corresponding runtime and certificate dependency updates, check the executable file path where the service is actually running to avoid that the terminal has switched to a new version and the daemon still uses the old installation directory. For multi-environment Python, service containers and applications that come with their own runtime, they should be checked separately.
For components that need to be rebuilt, save the build version, dependency version, and deployment image ID. The acceptance object is the actual running instance and cannot just check the new tag in the build machine or image registry. 71214
Website certificate migration
If a website’s chain contains a revoked or blocked intermediate CA, or ultimately relies on a distrusted root, obtain another chain that clients still accept. Install the complete server certificate chain and check every ingress, including load balancers, reverse proxies, CDN endpoints, and directly accessible origins. 15
Whether migration is required is based on the actual chain. Filtering only by certificate sales brand may miss resale or cross-signing relationships; just waiting for regular expiry renewal may not necessarily complete the migration before the root store is updated.
For other normal website certificates issued by CA that do not rely on the affected root, there is no need to re-sign them because of this incident. At the same time, the website server itself should still perform client-side repair checks when calling external services.
7 Verify that the fix actually takes effect
Version checking and behavior checking are performed separately
Version checks are used to confirm that patches or fixed components have been deployed; behavioral checks are used to confirm that the application actually uses the expected verification path. The two checks solve different problems, and neither of them can be replaced by “Update command executed successfully”.
The event maintainer provides test site and certificate chain materials, and the entrance is concentrated in appendix 4. It should be verified in the actual operating environment of the target application, maintaining the normal certificate verification configuration. 47
| Check results | Conclusions that can be drawn |
|---|---|
| Explicitly reject because the affected chain is not trusted | Indicates that the verification path being tested rejected the chain |
| Accept the affected chain normally | Indicates that this path needs to continue to be repaired or the configuration checked. |
| DNS error, connection timeout, proxy rejection or service unreachable | It cannot be concluded that the certificate risk has been eliminated based on this. |
| Browser rejects, but app call is not checked | It can only confirm the browser, not the background program. |
| A chain was rejected | Still need to consider whether the client accepts another cross-signing path |
The test should also cover normal business connections to avoid mistaking all request failures as successful repairs after business failures are caused by removing too much trust.
Suggested completion conditions
- The update source and version of the affected components are documented.
- The corresponding running instance has been restarted, rebuilt, or redeployed.
- The actual application rejects the affected chain, and TLS verification for normal business continues to work.
- There is no configuration to temporarily turn off certificate verification in order to restore the connection.
- If website certificate migration is involved, all external entrances have been switched and verified.
The above completion conditions are suggestions for operation and maintenance acceptance for this disposal; it is not equivalent to proving that the equipment has no other safety issues.
8 Historical HTTPS traffic and risk boundaries
Three types of keys have different uses
| key | Main purpose |
|---|---|
| CA private key | Sign the identity and public key binding in the certificate |
| Website private key | Prove server identity in certificate authenticated TLS handshake |
| session key | Protect the data actually transmitted on a connection |
Obtaining the CA private key is not equivalent to obtaining the website private key or all session keys. A normal connection with forward secrecy using temporary key exchange will not automatically expose historical sessions simply because the long-term signing key is later compromised. For the relevant security attributes of TLS 1.3, see RFC 8446. 16
The main risk this time occurs during the authentication phase: if the client accepts the fake server’s certificate, it may establish a connection with the attacker that is still encrypted. TLS 1.3 also requires trusted authentication; simply upgrading the protocol version is not a substitute for blocking CA.
Judgments that can and cannot be made at present
Confirmed: the specific intermediate CA private keys are compromised; the affected public trust paths have broad reach; major platforms and several software ecosystems have taken action. 145
Not established by this incident: that all users have experienced man-in-the-middle attacks, that other CA private keys are compromised, that all historical HTTPS traffic is decryptable, or that updating one browser protects every application on the device.
The final judgment about a specific service should be based on its certificate chain, verification policy, actual running components and update status, not just whether the address bar reads HTTPS.
Appendix A Affected intermediate CA name
The following names assist asset checks. Names do not replace certificate fingerprints or public-key identifiers. Automated matching should use the exact identifiers published by the incident maintainers or vendors, including cross-signed certificates. 5
| Middle CA | Purpose | Associated organizations |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | code signing | eMudhra BV |
| EM OV CS CA - G3C | code signing | eMudhra Inc |
TLS is not exactly the same validator and revocation mechanism as code signing. The focus of this article is HTTPS/TLS; the code signing environment should adopt Microsoft, JDK or related software vendors for this verification purpose, and the browser test results should not be regarded as code signing acceptance. 515
Appendix B Reference link
The following sources were verified on October 22, 2026. The rolling announcement may continue to be updated, and the status and version in the text should be understood based on the date of this document.
Incident facts and platform handling
[1] Google Chrome and Android Official Announcement Describes private key flaws, SPKI blocking, Google Play service distribution, CT protection, and Chrome root repository removal plans. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 Event record Contains original reports, independent verification, generation process investigation, subsequent fixes for Firefox Android, and legal certificate migration discussions; focus on comments 5, 11, 29, and 30. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox Security Notice Description of OneCRL emergency distribution and subsequent Firefox/NSS disposal. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] Event coordinator Dennis Jackson Maintenance summary and detection portal Provides supplementary instructions on platform and software repair status, test entrance, public certificate chain materials, and environments such as Windows/macOS. Test results only represent the actual verification paths tested. eMudhra Intermediate CA Compromise
[5] Mozilla Notice to distribution and truststore maintainers Describes 6 TLS and 2 code signing intermediates CA, Sectigo cross-signing, revocation, and root trust processing boundaries, and lists the exact certificate and public key identification. oss-security eMudhra Intermediates Compromise
[6] eMudhra Official Event Statement Provide the manufacturer’s preliminary explanation of the key generation process; the exact root cause will still be subject to the conclusion of the completed investigation. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare Official incident and repair instructions Covers WARP, Cloudflare Tunnel, origin site verification, runtime dependencies, image updates and verification methods. 8 eMudhra certificates are compromised Here is what you need to know
Operating systems and distributions
[8] Ubuntu Official Repair Announcement Lists the ca-certificates fix packages, support channels and targeted update steps for each version. eMudhra CA compromise fixes available
[9] Debian Official problem and repair record The maintainer’s fix record and the corresponding release package should be taken as the standard, and early temporary suggestions in the problem discussion should not be regarded as the final solution. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat Official Safety Bulletin RHSB 2026 012 Lists RHEL 6 through 10, associated product and container impacts, and fix release and interim disposal entries. Certificate compromise eMudhra
[11] FreeBSD Official Security Bulletin Provide affected system branches, repair versions and service restart requirements. FreeBSD SA 26 73 caroot
Runtime and protocols
[12] Python Official event description Provides repair baselines for pip, certifi, uv, etc., explains the problem of the old pip independent trust store, and provides the initial upgrade method with SHA-256 verification. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 Official release Contains NSS root store updates and rejects changes containing blocked public key certificate chains. Node.js 24.22.1 security release
[14] Go Official security release Description crypto/x509 certificate chain filtering update for Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK Official Disposal Instructions Explain the JDK critical patch and related configuration measures when it cannot be upgraded immediately. Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 Protocol standard RFC 8446 See appendix E.1 for instructions on identity authentication, temporary key exchange and forward secrecy. The Transport Layer Security Protocol Version 1.3
[17] Event-related root certificate and issuance relationship data Used to understand the direct issuer and cross-signing relationship; the root store inclusion status cannot replace the latest revocation or blocking status of the client. Root certificate relationships JSON