2085612 - eMudhra: Access to CRLs blocked for certain User-Agent headers

Status: UNCONFIRMED

(CA Program :: CA Certificate Compliance, defect)

Description

[Q Misell]

Jacob Durham reported in Comment 44 on Bug 2083449 that, as of (at least) their checks at 04:16 UTC on the 25th of October 2026, eMudhra's servers blocks access to the following hosts with the default cURL, wget, and Python's urllib User-Agent header:

• crl.emsign.com
• ocsp.emsign.com
• ocsp-b.emsign.com
• repository.emsign.com

At 09:34 UTC I confirmed this to be the case independently. Access to those hosts is blocked with a User-Agent of curl/8.7.1 but accepted with a User-Agent of check/1.

> GET /?roottlscag3.crl HTTP/1.1
> Host: crl.emsign.com
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Connection: close
< Content-Type: text/html
< Cache-Control: no-cache
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Content-Security-Policy: frame-ancestors 'self'
< Content-Length: 35576

> GET /?roottlscag3.crl HTTP/1.1
> Host: crl.emsign.com
> Accept: */*
> User-Agent: check/1
>
< HTTP/1.1 200
< Set-Cookie: JSESSIONID=crl1~20408A363CE9B81415F572D24A96CE46; Path=/; HttpOnly
< Date: Sun, 25 Oct 2026 09:34:39 GMT
< Pragma: no-cache
< Cache-Control: no-cache, no-store, must-revalidate
< Content-Disposition: attachment; filename="roottlscag3.crl"
< Last-Modified: Sun, 18 Oct 2026 09:38:46 GMT
< Expires: Fri, 16 Apr 2027 09:38:46 GMT
< Content-Type: application/pkix-crl
< Content-Length: 796

Comment 1

[JACOB DURHAM]

eMudhra: evidence for this bug, and questions.

What happens. Over HTTP, eMudhra's endpoints on 103.165.181.22 (crl, ocsp, ocsp-a, ocsp-b) and 103.165.181.23 (repository) refuse four HTTP clients by User-Agent: curl, Wget, Python-urllib and libwww-perl. They get a 403 page reading "This transfer is blocked by a Web Application Firewall", with "Event Type: signature" and Event ID 110000003 (110000006 for Python-urllib). Any other User-Agent gets the CRL, OCSP response or certificate.

curl -s -o /dev/null -w '%{http_code}\n' 'http://crl.emsign.com?roottlscag3.crl'               # 403
curl -s -o /dev/null -w '%{http_code}\n' -A check/1 'http://crl.emsign.com?roottlscag3.crl'   # 200

Coverage. On 25 October, 17:17-17:27 UTC, every CRL, OCSP and caIssuers URL that eMudhra discloses in CCADB, or names in its CA certificates and test-site certificates, was requested twice from one machine, seconds apart: as curl, and as check/1. The wire traces show each pair differs only in the User-Agent header. On the five filtered hostnames, curl was refused 417 of 417 times, covering 145 CRL URLs, 59 CA certificate URLs and OCSP checks for 104 certificates, by POST and by GET. check/1 got valid data 417 of 417 times, checked with OpenSSL. HTTPS is not filtered, and neither are crl-c and ocsp-c (209.43.12.165). Unchanged at 17:40 UTC.

Not a rate limit. The first request to each host was refused. mycurl/1, curl-check/1 and an empty User-Agent are served; Curl/8 and foo curl bar are refused. A request is refused when its User-Agent contains one of these client names; a client that renames itself gets through.

The incident revocations. roottlscag3.crl and rootcscag3.crl, which carry the eight cACompromise entries in Bug 2083449 comment 10, are refused, as are all eight intermediates' own CRLs. The G3B intermediates name ocsp-b as their OCSP responder, and it is filtered too. For the eMudhra-issued G3B certificates, neither revocation path answers these clients. These entries must stay published until the certificates expire on 28 April 2040 (BR 4.10.1).

Controls. The same harness run against other operators found none filtering curl: DigiCert, Sectigo, GlobalSign, SSL.com, Google Trust Services, Let's Encrypt, GoDaddy and Amazon each served every User-Agent tested on their revocation endpoints. The one parallel is Microsoft: www.microsoft.com (Akamai) returns 403 to the Wget User-Agent on its CRL and CA-certificate paths -- 2,355 of its 3,862 own-domain CRL URLs -- while serving curl and other clients; its dedicated crl2.microsoft.com is unaffected. So eMudhra is not the only operator filtering by User-Agent, but its filter is broader: curl, Wget, Python-urllib and libwww-perl, across its dedicated revocation hosts.

Requirements.

• BR 2.4: "The CA shall make its Repository publicly available in a read-only manner."
• BR 4.9.7: "CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published")."
• BR 4.10.2: "an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates".
• BR 7.1.2.11.2: CRL Distribution Point URIs "MUST be "http"", so HTTPS is not an alternative for software following the certificate.
• Mozilla Root Store Policy 6: "an online 24x7 repository mechanism whereby application software can automatically check online the current status of all unexpired certificates".
• eMudhra SSL/TLS CP/CPS v1.09 2.4, and Code Signing CP/CPS v1.02 2.4: the repository is "publicly accessible and provided with unrestricted, read-only access. This includes CA certificates, CRLs".

On Bug 2083449 comment 43. At 03:53 UTC eMudhra wrote that "Revocation status has been available via CRL and OCSP since that point", and that a relying party that checks "has not been exposed since the revocation". For relying-party software built on these four clients, that was not accurate then, or at any time it was tested on 25 October. Comment 44 described the filter to eMudhra at 04:23 UTC. There has been no reply. The filter was unchanged 13 hours after that, and still unchanged when re-probed the next day at 00:49 UTC on 26 October, about 21 hours after comment 43: all four filtered hostnames still returned 403 to curl, Wget and Python-urllib and 200 to other clients over HTTP, and roottlscag3.crl served to an allowed client still parsed as a valid CRL (lastUpdate 18 October, nextUpdate 16 April 2027). The CCADB guidelines say that if a described impact "is later found to be inaccurate, the CA Owner MUST clearly communicate a correction".

Questions.

1. When was the filter first applied to each hostname (UTC), and by which change? Was it in place on 17 October?
2. Why was it applied, who approved it, and did the change review consider BR 2.4, 4.9.7 and 4.10.2, and CP/CPS 2.4?
3. What are the full match conditions for signatures 110000003 and 110000006, and which hostnames do they cover?
4. From the firewall logs, how many CRL, OCSP and caIssuers requests were refused, in total and since 18 October 09:24 UTC? (CP/CPS 5.4.1 lists firewall activity among recorded events.)
5. When will the filter be removed from every CRL, OCSP and caIssuers URL?
6. Will eMudhra correct comment 43, and respond to this report within the 72 hours the CCADB guidelines allow?

Wire traces, response bodies and a SHA-256 manifest covering 8,242 files are available on request.