Over in rustls/rustls-ffi#324 (comment) we discussed how using CRLs with ClientCertVerifier comes with certain implicit requirements that we should make explicit in the docs. CRLs should be updated on some interval, which is likely to be shorter than the restart interval of the TLS server. Since with_crls is called on AllowAnyAnonymousOrAuthenticatedClient (and friend) and construction time, it means the old-school way of building a ServerConfig once per server doesn't work.
Instead, to be able to update CRLs periodically, you need to use the Acceptor API, and construct a new ClientCertVerifier on each handshake, using whichever set of CRLs has been fetched most recently.
There's also a subtlety that should be called out in the docs: because the client certificate is not available in the ClientHello, the server needs to know ahead of time what CRLs it cares about. For client revocation specifically, that's probably okay, because client authentication issuer hierarchies are (I think!) usually simple, and the server can usually be configured ahead of time to know what CRLs to care about. However, it might be a surprise to some users who are expecting to be able to fetch a CRL from the CRL Distribution Points extension of a client certificate at handshake time.
Over in rustls/rustls-ffi#324 (comment) we discussed how using CRLs with ClientCertVerifier comes with certain implicit requirements that we should make explicit in the docs. CRLs should be updated on some interval, which is likely to be shorter than the restart interval of the TLS server. Since with_crls is called on AllowAnyAnonymousOrAuthenticatedClient (and friend) and construction time, it means the old-school way of building a ServerConfig once per server doesn't work.
Instead, to be able to update CRLs periodically, you need to use the Acceptor API, and construct a new ClientCertVerifier on each handshake, using whichever set of CRLs has been fetched most recently.
There's also a subtlety that should be called out in the docs: because the client certificate is not available in the ClientHello, the server needs to know ahead of time what CRLs it cares about. For client revocation specifically, that's probably okay, because client authentication issuer hierarchies are (I think!) usually simple, and the server can usually be configured ahead of time to know what CRLs to care about. However, it might be a surprise to some users who are expecting to be able to fetch a CRL from the CRL Distribution Points extension of a client certificate at handshake time.