You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 2, 2024. It is now read-only.
Chromium uses an indirect approach for certificate revocation checking: https://dev.chromium.org/Home/chromium-security/crlsets (Once a day, a CRX file is downloaded which contains a list of revoked certificates, collected by a crawler).
The standard approach is to use the OCSP protocol, which allows a client to query the validity of a certificate by sending a request (over a subset of HTTP) to a URI provided in the certificate. The CA responds with a timestamped and signed response. This response can either be consumed by a client directly (to verify the certificate of a server) or can be used by a server to implement OCSP stapling (server sends the response from the CA to the client during a handshake).
In terms of testing, Chromium maintains its own cert store, which it uses, in a testing environment to populate a native certificate verification context. The problem is that populating this context requires fiddling with undocumented APIs (HCERTCHAINENGINE) on Windows, which doesn't seem to be the right approach, not to mention the fact that there are basically 2 paths in the code - the "production" path and the "testing" path.
We should research Chromium's interfaces, for example:
https://github.com/chromium/chromium/blob/3c74836d8b7f780a875758af530bc2194ef0e39c/net/cert/caching_cert_verifier.h#L46
In the research (which should go into the documentation as an appendix) we can describe what Chromium does, and then compare it to what Certify does.
The text was updated successfully, but these errors were encountered: