Repository navigation
Accept expired TLS certificate if the fingerprint does not change #7996
Description
Activity
I have now looked into writing a custom certificate verifier. All the certificate verification logic in Rustls is available as a function https://docs.rs/rustls/0.23.37/rustls/client/fn.verify_server_cert_signed_by_trust_anchor.html which checks the whole certificate chain. It calls https://docs.rs/rustls-webpki/0.103.10/webpki/struct.EndEntityCert.html#method.verify_for_usage in turn. There is a
nowparameter passed through, but there is no way to say that we are ok with expired leaf ("end-entity") certificate without reimplementing rustls-webpki logic that it does not expose.We can still remember the fingerprint of the public key and accept certificate if the public key does not change, but will have to drop the idea of accepting valid but expired certificates for users who have just upgraded and have no stored public key hash.
TLS certificates expiring is rarely a security problem. In most cases TLS certificate expires because certificate update automation failed. During internet shutdowns certificates automatically updated with ACME fail to renew and expire eventually. Sometimes server owner loses control over domain name and cannot renew certificates afterwards even with DNS challenges. In these cases existing users should not lose access. We also don't want users to "fix" the problem by disabling certificate checks completely when certificates expire.
We should remember the fingerprint of the leaf certificate (EDIT: or the fingerprint of the public key) and accept expired certificates when the fingerprint matches the remembered one.
When there is no remembered fingerprint, e.g. after upgrade from the version without this change, we should also accept expired certificates. This will help users who are already using the server with expired certificate to fix the problem by upgrading the client.EDIT: this is not feasible to implement accepting "valid but expired" certificates when we have no remembered fingerprint, see #7996 (comment)Expired certificates should not be accepted during initial configuration. Otherwise any leaked certificate with a key can be reused forever to setup a new server. Expired key may even be added to the test data, and it should not be usable. If the server certificate cannot be renewed maybe it should not accept new users. For self-signed certificates we need certificate fingerprint pinning via
dcaccount, it is a separate problem.Fingerprint should be remembered per hostname, could be simply a new SQL table with the hostname, last seen fingerprint and a timestamp. If we have not seen any fingerprint for a long time, e.g. because some transport was removed, the record should eventually be cleaned up.