OCSP
A protocol for querying certificate revocation status online; when OCSP fails, clients may adopt a soft-fail policy and continue the connection, creating a security window.
Timeline (last 90 days)
Modern browsers and operating systems have certificate revocation mechanisms (such as CRL and OCSP), which can isolate problematic certificates relatively quickly.
The main costs of a private CA lie in CA key protection, certificate revocation (CRL/OCSP) and high-availability operations; if mismanaged, private key leakage will cause the entire internal trust system to fail.
A custom certificate bundle specified via http.sslCAInfo requires tracking the certificate revocation list (CRL) or OCSP status oneself, and the configuration only applies to the current repository or globally to Git, without affecting other tools.
To respond to an intermediate certificate private key leak, the standard practice is for the CA to add the leaked certificate to a revocation list (CRL) or mark it revoked via OCSP, and for relying parties to update their trust stores.
When a CA exits the business, if the CRL/OCSP services go offline early, clients will be unable to confirm certificate status, and some strict-mode browsers or systems may report errors directly.
Common certificate revocation mechanisms include certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP); browsers usually have built-in revocation checks or rapidly update root certificate lists, but system-level trust stores are updated less frequently, and many command-line tools do not perform real-time revocation queries by default.
Certificate revocation list (CRL) update intervals may be as long as several hours to several days, OCSP responses may be cached, and some clients adopt a "soft-fail" strategy, so the attack window may last for hours or even days.
The commercial CA system relies on CRL and OCSP to propagate revocation information, but revocation propagation is delayed, some clients do not check OCSP strictly, and revocation of an interception certificate affects all traffic relying on that intermediate CA.
Certificate revocation lists (CRL) and OCSP responses have propagation delays, and some clients also adopt a "soft-fail" policy of continuing the connection when OCSP fails.
Industry mitigation measures include Certificate Transparency (CT), certificate revocation mechanisms (CRL/OCSP), HSTS, and Certificate Pinning.
All Facts (10)
Modern browsers and operating systems have certificate revocation mechanisms (such as CRL and OCSP), which can isolate problematic certificates relatively quickly.
50%UnverifiedThe main costs of a private CA lie in CA key protection, certificate revocation (CRL/OCSP) and high-availability operations; if mismanaged, private key leakage will cause the entire internal trust system to fail.
50%UnverifiedA custom certificate bundle specified via http.sslCAInfo requires tracking the certificate revocation list (CRL) or OCSP status oneself, and the configuration only applies to the current repository or globally to Git, without affecting other tools.
50%UnverifiedTo respond to an intermediate certificate private key leak, the standard practice is for the CA to add the leaked certificate to a revocation list (CRL) or mark it revoked via OCSP, and for relying parties to update their trust stores.
50%UnverifiedWhen a CA exits the business, if the CRL/OCSP services go offline early, clients will be unable to confirm certificate status, and some strict-mode browsers or systems may report errors directly.
50%UnverifiedCommon certificate revocation mechanisms include certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP); browsers usually have built-in revocation checks or rapidly update root certificate lists, but system-level trust stores are updated less frequently, and many command-line tools do not perform real-time revocation queries by default.
50%UnverifiedCertificate revocation list (CRL) update intervals may be as long as several hours to several days, OCSP responses may be cached, and some clients adopt a "soft-fail" strategy, so the attack window may last for hours or even days.
50%UnverifiedThe commercial CA system relies on CRL and OCSP to propagate revocation information, but revocation propagation is delayed, some clients do not check OCSP strictly, and revocation of an interception certificate affects all traffic relying on that intermediate CA.
50%UnverifiedCertificate revocation lists (CRL) and OCSP responses have propagation delays, and some clients also adopt a "soft-fail" policy of continuing the connection when OCSP fails.
50%UnverifiedIndustry mitigation measures include Certificate Transparency (CT), certificate revocation mechanisms (CRL/OCSP), HSTS, and Certificate Pinning.
50%