FETCH-CRL(8) | System Manager's Manual | FETCH-CRL(8) |
fetch-crl - retrieve certificate revocation lists
fetch-crl [-c config] [-v[v..]] [-q] [-h] [--inet6glue] [-l infopath] [-o outputpath] [-s statepath] [-a agingtolerance] [-T httptimeout] [-r randomwait] [-p parallelism] [--formats openssl|pem|der|nss] .. [--define key=value] .. [--cfgdir dirname]
The fetch-crl utility will retrieve certificate revocation lists (CRLs) for a set of installed trust anchors, based on crl_url files or IGTF-style info files. It will install these for use with OpenSSL, NSS or third-party tools.
It works based on a list of trust anchors, for each of which one or more CRLs should be installed in a CRL store. And for each of these CRLs, one or more URLs can be specified from which the specific CRL can be retrieved. There are several supported formats for CRL stores:
OpenSSL in version 1 changes its subject name hashing algorithm, though, so that for one trust anchor two hashes could be used, depending on the specific OpenSSL version at hand. If OpenSSL version 1 or higher is used by fetch-crl and the default mode is used, each CRL is written out twice, once for each possible hash value. This mode in controlled by the opensslmode = { dual | single } configuration option in the configuration file.
Each CRLs can be retrieved from one of several URLs. These URLs are listed by default in the trust anchor meta-data: the .info file or the .crl_url file, as shipped with the trust anchor. In the crl_url file, there is one URL per line; in the .info file, the crl_url attribute is a semi-colon separated list of URLs. These URLs are then tried in order to retrieve a fresh CRL. Once data has been successfully retrieved, this data is used as the CRL if it passes verification, signature checking and expiration checks. Http, https, ftp and file URLs are supported. If data for a CRL has been downloaded but this data fails any of the subsequent checks (signature validation, freshness), the CRL data is discarded and NO further URLs are tried for this CRL!
URLs can be pre-pended or post-pended to the default list via the configuration file. This can be used to prefer a local mirror repository over any URLs shipped by the trust anchor provider, without the need to modify the trust anchor metadata. By post-pending a URL, a 'last-resort' download location can be added in case the CA provided URLs cannot be used. The pre- and post-pended URLS are subject to token expansion of the tokens @ALIAS@, @ANCHORNAME@, and @R@, where R is the sequence number of the CRL on a per-trust anchor basis.
Retrieved CRLs may be PEM (RFC1421) or DER encoded. They are automatically converted as needed by fetch-crl, using the OpenSSL command-line tool.
Retrieving a CRL without having an accompanying CA root certificate in an OpenSSL-accessible form (like @ALIAS@.0 or @ANCHORNAME@.@R@ will result in a verification failures. The CA lookup directory and patterns can be configured via the configuration file
In paths and name templates, tokens are expanded to allow a single pattern to be used for all trust anchors. The nametemplate_*, catemplate, prepend_url, and postpend_url configuration settings are subject to token expansion.
The following tokens are recognised
Default: 24 hour aging tolerance
See http://wiki.nikhef.nl/grid/FetchCRL3 or the included example file for a description of the configuration options. The default location of the configuration file is /etc/fetch-crl.conf. Supplementary configuration is read from all files located in /etc/fetch-crl.d/, or the directory designated by the cfgdir directive, whose collated contents are added to the existing configuration data.
Defaults can be set in the fetch-crl system configuration file /etc/fetch-crl.conf.
openssl(1), http://wiki.nikhef.nl/grid/FetchCRL3
Exit status is normally 0; if an error occurs, exit status is 1 and diagnostics will be written to standard error.
Licensed under the Apache License, Version 2.0 (the "License");
http://www.apache.org/licenses/LICENSE-2.0
Although fetch-crl3 will install multiple CRLs in the CRL stores (called '.r0', '.r1', or labelled appropriately in an NSS store), if the number of CRLs decreases the left-overs are not automatically removed. So if the number of CRLs for a particular CA does down from n to n-1, the file '.rn' must be removed manually.
local | Trust Anchor Utilities |