Skip to content
Snippets Groups Projects
  • Thomas Bellman's avatar
    71eecc0b
    Configure fetch-crl to cache for short times. · 71eecc0b
    Thomas Bellman authored
    We have found a problem with some CA CRL distribution points and the
    fetch-crl caching logic.  By default, fetch-crl caches the revocation
    lists it downloads (in /var/cache/fetch-crl), and keeps using that
    cached data until it is deemed no longer "fresh", and only then does
    it download a new updated CRL.  The limit on freshness is based on the
    Expires: and Cache-Control: headers that the CRL web server sends.
    
    The problem is, if the CRL servers sets Expires: to the same time that
    the CRL expires (the nextUpdate field of the CRL), fetch-crl will not
    download a new CRL until the cached CRL is no longer valid.
    
    This has apparently not been a big practical problem until now, as
    fetch-crl by default sets an upper limit of 4 days (96 hours) for how
    long it caches CRLs.  Since most CRLs have lifetimes longer than that
    (seven days is common), the cached data expires well before the CRL
    expires, and thus a new CRL will be downloaded in time.  Also, some
    CRL distribution points also send a Cache-Control: header with a
    max-age parameter of just a few hours, further limiting how long
    fetch-crl will cache those CRLs.
    
    The problem was noticed when a new GÉANT TCS CA was created, which
    gives out CRLs with a lifetime of just 2 days (48 hours), and just
    sets Expires: with end date equal to the CRL nextUpdate field.
    Suddenly web servers would get expired CRLs, and lock out users.
    
    Also, even if the CRLs have longer lifetimes than 4 days, having
    fetch-crl use up to four days old CRLs means that revocations are
    not propagated in a timely manner.  Most users probably prefer if
    a revoked certificate becomes unusable much sooner than 4 days.
    
    We work around this by configuring fetch-crl to have a maximum cache
    lifetime of only one hour.  While the default fetch-crl cron job only
    runs every six hours, it should still ensure CRLs are refreshed in a
    reasonably timely manner.
    
    We set the 'maxcachetime' parameter in the main /etc/fetch-crl.conf
    config file.  Users can then override our choice using the
    x509certs::fetchcrl::option definition.
    71eecc0b
    History
    Configure fetch-crl to cache for short times.
    Thomas Bellman authored
    We have found a problem with some CA CRL distribution points and the
    fetch-crl caching logic.  By default, fetch-crl caches the revocation
    lists it downloads (in /var/cache/fetch-crl), and keeps using that
    cached data until it is deemed no longer "fresh", and only then does
    it download a new updated CRL.  The limit on freshness is based on the
    Expires: and Cache-Control: headers that the CRL web server sends.
    
    The problem is, if the CRL servers sets Expires: to the same time that
    the CRL expires (the nextUpdate field of the CRL), fetch-crl will not
    download a new CRL until the cached CRL is no longer valid.
    
    This has apparently not been a big practical problem until now, as
    fetch-crl by default sets an upper limit of 4 days (96 hours) for how
    long it caches CRLs.  Since most CRLs have lifetimes longer than that
    (seven days is common), the cached data expires well before the CRL
    expires, and thus a new CRL will be downloaded in time.  Also, some
    CRL distribution points also send a Cache-Control: header with a
    max-age parameter of just a few hours, further limiting how long
    fetch-crl will cache those CRLs.
    
    The problem was noticed when a new GÉANT TCS CA was created, which
    gives out CRLs with a lifetime of just 2 days (48 hours), and just
    sets Expires: with end date equal to the CRL nextUpdate field.
    Suddenly web servers would get expired CRLs, and lock out users.
    
    Also, even if the CRLs have longer lifetimes than 4 days, having
    fetch-crl use up to four days old CRLs means that revocations are
    not propagated in a timely manner.  Most users probably prefer if
    a revoked certificate becomes unusable much sooner than 4 days.
    
    We work around this by configuring fetch-crl to have a maximum cache
    lifetime of only one hour.  While the default fetch-crl cron job only
    runs every six hours, it should still ensure CRLs are refreshed in a
    reasonably timely manner.
    
    We set the 'maxcachetime' parameter in the main /etc/fetch-crl.conf
    config file.  Users can then override our choice using the
    x509certs::fetchcrl::option definition.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.