SLVS-3039 [TEST] Disable certificate revocation check

[georgii-borovinskikh-sonarsource]

Part of DEX-16

[hashicorp-vault-sonar-prod]

SLVS-3039

[gitar-bot]

🚨 Security: Revoked server certificates now accepted as trusted (TLS MITM)

ValidateChain is the only server-trust decision in the product: HttpConfigurationListener.CheckServerTrustedAsync returns its boolean straight back to SLCore as CheckServerTrustedResponse, and there is no secondary check or user confirmation anywhere (the notification is informational only). X509ChainPolicy.RevocationMode defaults to Online, so setting NoCheck means a server presenting a certificate whose issuer has already revoked it (stolen/compromised key, decommissioned host) now yields Build() == true and the connection to SonarQube is trusted — exactly the case revocation exists to stop. If the goal is to tolerate an unreachable CRL/OCSP endpoint (air-gapped or proxy-blocked machines, which produce RevocationStatusUnknown and a false result), keep revocation active and ignore only the unknown status instead of accepting revoked certificates.

Fix 1: Keep online revocation checking, but do not fail when the revocation status cannot be determined. Revoked certificates are still rejected.

using var x509Chain = new X509Chain();
// Tolerate unreachable CRL/OCSP endpoints (offline/proxied machines) without
// accepting certificates that are known to be revoked.
x509Chain.ChainPolicy.VerificationFlags |= X509VerificationFlags.IgnoreEndRevocationUnknown
    | X509VerificationFlags.IgnoreCertificateAuthorityRevocationUnknown
    | X509VerificationFlags.IgnoreRootRevocationUnknown;

• Apply fix

Fix 2: If the motivation is avoiding network calls/latency during validation, use Offline mode so cached CRLs are still honoured, rather than skipping revocation entirely.

using var x509Chain = new X509Chain();
// Use locally cached CRLs only - no network calls during chain building.
x509Chain.ChainPolicy.RevocationMode = X509RevocationMode.Offline;

• Apply fix

_{Check a box to apply a fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

⚠️ This PR is blocked due to unresolved code review findings.

Comment gitar unblock to override this block and allow merging.

_{Configure merge blocking · Maintainers can dismiss this review.}

[gitar-bot]

Code Review 🚫 Blocked 0 resolved / 1 findings

Disables certificate revocation checking in the TLS validation path, but this creates a critical security vulnerability: revoked server certificates are now accepted as trusted, enabling potential MITM attacks. Additionally, the temporary test change lacks any marker, flag, or test guard to prevent accidental production deployment. Revocation checking should remain enabled; if the goal is to tolerate unreachable CRL/OCSP endpoints, keep revocation active and ignore only the unknown status instead of accepting revoked certificates.

🚨 Security: Revoked server certificates now accepted as trusted (TLS MITM)

📄 src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:49-50 📄 src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:59-70 🔗 X509ChainPolicy.RevocationMode defaults to Online 🔗 X509VerificationFlags 📄 src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:45 📄 src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:50

ValidateChain is the only server-trust decision in the product: HttpConfigurationListener.CheckServerTrustedAsync returns its boolean straight back to SLCore as CheckServerTrustedResponse, and there is no secondary check or user confirmation anywhere (the notification is informational only). X509ChainPolicy.RevocationMode defaults to Online, so setting NoCheck means a server presenting a certificate whose issuer has already revoked it (stolen/compromised key, decommissioned host) now yields Build() == true and the connection to SonarQube is trusted — exactly the case revocation exists to stop. If the goal is to tolerate an unreachable CRL/OCSP endpoint (air-gapped or proxy-blocked machines, which produce RevocationStatusUnknown and a false result), keep revocation active and ignore only the unknown status instead of accepting revoked certificates.

Keep online revocation checking, but do not fail when the revocation status cannot be determined. Revoked certificates are still rejected.

using var x509Chain = new X509Chain();
// Tolerate unreachable CRL/OCSP endpoints (offline/proxied machines) without
// accepting certificates that are known to be revoked.
x509Chain.ChainPolicy.VerificationFlags |= X509VerificationFlags.IgnoreEndRevocationUnknown
    | X509VerificationFlags.IgnoreCertificateAuthorityRevocationUnknown
    | X509VerificationFlags.IgnoreRootRevocationUnknown;

If the motivation is avoiding network calls/latency during validation, use Offline mode so cached CRLs are still honoured, rather than skipping revocation entirely.

using var x509Chain = new X509Chain();
// Use locally cached CRLs only - no network calls during chain building.
x509Chain.ChainPolicy.RevocationMode = X509RevocationMode.Offline;

🤖 Prompt for agents

Code Review: Disables certificate revocation checking in the TLS validation path, but this creates a critical security vulnerability: revoked server certificates are now accepted as trusted, enabling potential MITM attacks. Additionally, the temporary test change lacks any marker, flag, or test guard to prevent accidental production deployment. Revocation checking should remain enabled; if the goal is to tolerate unreachable CRL/OCSP endpoints, keep revocation active and ignore only the unknown status instead of accepting revoked certificates.

1. 🚨 Security: Revoked server certificates now accepted as trusted (TLS MITM)
   Files: src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:49-50, src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:59-70, src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:45, src/SLCore.Listeners/Implementation/Http/ICertificateChainValidator.cs:50

   `ValidateChain` is the only server-trust decision in the product: `HttpConfigurationListener.CheckServerTrustedAsync` returns its boolean straight back to SLCore as `CheckServerTrustedResponse`, and there is no secondary check or user confirmation anywhere (the notification is informational only). `X509ChainPolicy.RevocationMode` defaults to `Online`, so setting `NoCheck` means a server presenting a certificate whose issuer has already revoked it (stolen/compromised key, decommissioned host) now yields `Build() == true` and the connection to SonarQube is trusted — exactly the case revocation exists to stop. If the goal is to tolerate an unreachable CRL/OCSP endpoint (air-gapped or proxy-blocked machines, which produce `RevocationStatusUnknown` and a `false` result), keep revocation active and ignore only the *unknown* status instead of accepting revoked certificates.

   Fix (Keep online revocation checking, but do not fail when the revocation status cannot be determined. Revoked certificates are still rejected.):
   using var x509Chain = new X509Chain();
   // Tolerate unreachable CRL/OCSP endpoints (offline/proxied machines) without
   // accepting certificates that are known to be revoked.
   x509Chain.ChainPolicy.VerificationFlags |= X509VerificationFlags.IgnoreEndRevocationUnknown
       | X509VerificationFlags.IgnoreCertificateAuthorityRevocationUnknown
       | X509VerificationFlags.IgnoreRootRevocationUnknown;

   Fix (If the motivation is avoiding network calls/latency during validation, use Offline mode so cached CRLs are still honoured, rather than skipping revocation entirely.):
   using var x509Chain = new X509Chain();
   // Use locally cached CRLs only - no network calls during chain building.
   x509Chain.ChainPolicy.RevocationMode = X509RevocationMode.Offline;

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact	Unblock
gitar auto-apply:on	gitar display:verbose	gitar unblock

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud