OCSP revocation check does not block connections to sites with revoked certificates

[man-pro]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

2.18.0.2089

Browser version

n/a

OS version

macOS Tahoe 26.3.1

Ad Blocking

No response

Privacy

No response

Social

No response

Annoyances

No response

Security

No response

Other

No response

Language-specific

No response

Which DNS server do you use?

DNS protection disabled

DNS protocol

None

Custom DNS

No response

What Stealth Mode options do you have enabled?

No response

Support ticket ID

No response

Issue Details

With network.https.ocsp.check set to true, AdGuard for Mac still establishes connections to servers whose TLS certificates have been revoked. The revocation status is confirmed by the server itself via OCSP Stapling, by an independent OCSP query, and by asset management tools.

Steps to reproduce:

1. Set network.https.ocsp.check to true in Advanced Settings.
2. Visit https://www.reiner-sct.com (certificate is currently revoked).
3. AdGuard establishes the connection without warning or blocking.

Expected behavior:

AdGuard should detect the revoked certificate and block the connection, as documented: "If the certificate is revoked, current and future connections to the domain will be blocked."

Actual behavior:

The connection is established normally. No warning, no blocking.

Evidence:

The server delivers an OCSP Stapled Response with status revoked during the TLS handshake:

OCSP Response Status: successful (0x0)
Responder Id: C = DE, O = D-Trust GmbH, CN = D-TRUST OCSP 23 SSL Class 3 CA 1 EV 2009
Produced At: Apr 7 11:48:42 2026 GMT
Serial Number: 48B1F99AFF3C9ECFC336FAB2566B4D20
Cert Status: revoked

Verified independently via:

• openssl s_client -status (stapled response shows revoked)
• Direct OCSP query to the CA responder (returns revoked)
• Asset management tooling (reports revoked)

Impact:

This undermines the purpose of the revocation check feature entirely. Since AdGuard terminates the original TLS connection and presents its own certificate to the browser, the browser cannot perform its own revocation check on the original certificate. Users relying on AdGuard's OCSP check are left unprotected.

Expected Behavior

No response

Actual Behavior

This undermines the purpose of the revocation check feature entirely. Since AdGuard terminates the original TLS connection and presents its own certificate to the browser, the browser cannot perform its own revocation check on the original certificate. Users relying on AdGuard's OCSP check are left unprotected.

Screenshots

Screenshot 1

Additional Information

No response

[AlexandrPkhm]

@man-pro Hello!

Thank you for the report!

Could you please check if the issue is reproducible in the latest Nightly or Beta version of AdGuard for Mac? We have included the updated CoreLibs in those versions of the app, which feature CRLite library support.

If the issue still occurs, please collect your application logs and send them to us.
Here's what we need you to do:

1. Click AdGuard icon in the menu bar → Gear → Advanced → Logging → Logging level → Debug.
2. Reproduce the problem, then remember the exact time it happened.
3. Menu → Advanced → Logging → Export Logs and System Info.….
4. Send this file to qa@adguard.com:
   • include [mac] keyword and #1683 in the subject of your email
   • specify the exact time when the issue occurred

[AlexandrPkhm]

@man-pro It seems that reiner-sct.com has a valid, non-revoked certificate. You can check the Qualys SSL Labs report confirming this.

Does the issue occur on other websites?

[man-pro]

Thank you for looking into this.

The certificate has indeed been replaced since I filed the report. The revocation was part of a mass revocation by D-Trust, a German government-owned certificate authority (subsidiary of Bundesdruckerei). They were required to revoke all TLS certificates issued between March 15, 2025 and April 2, 2026 due to non-compliance with CA/Browser Forum rules regarding certificate linting. The deadline for revocation was Easter Monday, April 6, 2026, 17:00 CEST.

For context, here is a summary of the incident (source: https://www.heise.de/news/Fieses-Osterei-D-Trust-verlangt-Zertifikatstausch-bis-Ostermontag-11245930.html):

---

DE: D-Trust, die zur Bundesdruckerei gehörende Registrierungsstelle, hat kurzfristig alle zwischen dem 15.03.2025 und dem 02.04.2026 ausgestellten TLS-Zertifikate widerrufen. Hintergrund war ein Verstoß gegen die Regeln des CA/Browser Forums bei der automatischen Prüfung (Linting) von Zertifikaten. D-Trust hatte die Branchenregeln anders interpretiert als im technischen Konsens der Community üblich. Um einen vollständigen Vertrauensentzug durch die Browser-Hersteller und damit den Ausschluss aller D-Trust-Zertifikate aus den Root-Stores zu vermeiden, mussten die betroffenen Zertifikate bis Ostermontag, 06.04.2026, 17:00 Uhr ausgetauscht werden. Laut D-Trust bestand kein Sicherheitsproblem; das BSI bestätigte, dass kein Cyberangriff vorlag.

EN: D-Trust, a certificate authority owned by the German federal government (through Bundesdruckerei), revoked all TLS certificates issued between March 15, 2025 and April 2, 2026 on short notice. The reason was non-compliance with CA/Browser Forum rules related to certificate linting. D-Trust had interpreted the industry rules differently from the general technical consensus within the community. To avoid a full distrust by browser vendors — which would have resulted in the removal of all D-Trust certificates from browser root stores — the affected certificates had to be replaced by Easter Monday, April 6, 2026, 17:00 CEST. According to D-Trust, there was no security issue; Germany's Federal Office for Information Security (BSI) confirmed there was no cyberattack involved.

---

To answer your question: yes, the issue occurred on other websites as well. I observed the same behavior on at least one other site that was affected by the same D-Trust mass revocation. AdGuard did not block the connection despite the certificate being revoked. However, that site has also since replaced its certificate, so I can no longer use it for reproduction either.

So yes, the Qualys report now shows a valid certificate — because the site operator has since installed a new one. But at the time of my report, the certificate was revoked, which was confirmed by the OCSP Stapled Response included in the TLS handshake, by a direct OCSP query to the CA responder, and by asset management tooling.

The current OCSP Stapled Response for the new certificate confirms status good:

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = DE, O = D-Trust GmbH, CN = D-TRUST OCSP 23 SSL Class 3 CA 1 EV 2009
    Produced At: Apr  8 08:09:46 2026 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: F2DF2C4E376BC7C65576D2D882B6436BFAE1FC56
      Issuer Key Hash: D3BDF808A8E8641C389169963C74AEC48D1A88E2
      Serial Number: 4BD57DD07C7B45E69ED2E4B7B5DF9B00
    Cert Status: good

I cannot currently provide a revoked certificate for testing, as the affected certificate has been replaced. However, the core issue remains: when network.https.ocsp.check is set to true, AdGuard did not block a connection despite receiving a stapled OCSP response with status revoked. This means the feature did not work as documented.

I am happy to test again with the Nightly or Beta version if a revoked certificate becomes available for testing. Alternatively, if your team has a way to reproduce the scenario internally (e.g. using a test certificate with revoked status), that would be the most reliable path.

[AlexandrPkhm]

@man-pro Hello!

In AdGuard for Mac v2.18 if a certificate lacks an OCSP URL, the revocation check will not be performed. As mentioned previously, the upcoming CoreLibs version will include CRLiteDB, so the revocation check will be improved.

However, as we can see, in your case the certificate does contain an OCSP URL, and thus there might be a potential bug. We will investigate this further.