Refresh Mono Certificate Revocation Lists with crlupdate

You will use crlupdate to download missing or overdue certificate revocation lists (CRLs) for Mono, first in the current user's certificate store and then, if required, in the machine store. You will also verify which mode ran and understand when a forced refresh is appropriate. Allow about fifteen minutes, plus the time needed for the CRL servers to respond.

This guide describes the installed Mono package on this machine: mono-devel 6.8.0.105+dfsg-3.6ubuntu2. The command is a small wrapper around /usr/lib/mono/4.5/crlupdate.exe. Other Mono releases may use different store implementations, so treat the installed manual and help output as the local contract.

1. Check the installed command

Start with read-only checks. These do not need elevated privileges:

$ command -v crlupdate
/usr/bin/crlupdate
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
$ crlupdate -?
Usage: crlupdate [-m] [-v] [-f] [-?]

        -m      use the machine certificate store (default to user)
        -v      verbose mode (display status for every steps)
        -f      force download (and replace existing CRL)
        -?      Display this help message

Checkpoint: confirm that the command resolves to the Mono installation you intend to maintain. Do not assume that another runtime on PATH shares the same certificate stores.

2. Refresh the current user's store

With no options, crlupdate examines certificates in the user store and downloads a CRL when it is missing or past its due date. Run it as the affected user:

$ crlupdate -v

The -v option asks for extra status while downloading and updating. The exact lines depend on the certificates in your store, the CRL distribution points in those certificates and the network response. An ordinary successful run returns to the shell without an error. It does not mean that every certificate has a reachable CRL server.

Do not use sudo for this step. Running it as root would select root's user store rather than refreshing the store belonging to the account that runs your Mono application.

Checkpoint: repeat the command without verbosity if you want a quiet scheduled run:

$ crlupdate
$ printf 'exit status: %s\n' "$?"
exit status: 0

Exit status 0 confirms that the process completed successfully. It is not a report of how many CRLs changed. Keep the verbose output when investigating a particular certificate or network failure.

3. Decide whether the machine store is the right target

Use the machine store only when the certificates are consumed by services or applications that do not use one user's store. The machine store is shared state, so changes can affect multiple processes. First identify the service account and its certificate-store design; do not guess from the service name.

The machine-store operation requires read and write access to that store. The manual does not promise that every unprivileged user has it. If your system's store permissions require elevation, use an approved administrative shell for this step:

# crlupdate -m -v
# printf 'exit status: %s\n' "$?"
exit status: 0

The # prompt marks a command that may require administrative privileges. It is not a reason to use sudo automatically. Check the actual permissions and the account under which the consuming service runs.

There is no separate undo option. A normal update replaces or adds CRL data in the selected store. Before changing a shared machine store, take the backup or snapshot required by your operating procedure and record which account ran the command. If an update causes an application problem, restore that store from the approved backup, then investigate the certificate and CRL endpoint rather than repeatedly forcing downloads.

4. Understand normal updates versus forced updates

By default, the tool avoids downloading a CRL whose nextUpdate time is still in the future. That is the useful setting for routine maintenance: it limits unnecessary network traffic and avoids replacing a still-current list without a reason.

The -f option forces downloads for all CRLs associated with certificates in the selected store, even when their current lists are not due. This is a state-changing and network-dependent operation. Use it for a deliberate repair or investigation, not as a reflex when a verbose run is quiet.

$ crlupdate -v -f
# crlupdate -m -v -f

The first command forces the current user's store. The second forces the machine store and may need an administrative account. If the command fails part-way through, do not assume that every list was updated. Rerun the normal verbose command after checking the reported error, store permissions and network access.

5. Handle the common failure modes

A failure to download a CRL can come from the certificate's distribution point, DNS, a proxy, TLS validation or local store permissions. Capture the verbose output and the exit status:

$ crlupdate -v
$ status=$?
$ printf 'crlupdate exit status: %s\n' "$status"
crlupdate exit status: 1

The displayed status is an example of a failure, not a promise that every release uses exactly that number for every cause. Use the text printed by your installed build to find the failing certificate or endpoint. The manual documents the options, but it does not define a complete portable table of error codes.

If the user-store command works but the machine-store command does not, compare the effective account and store permissions before changing anything. If downloads fail for both stores, test the relevant CRL URLs and proxy policy using your normal network diagnostic process. Do not disable certificate verification or replace a certificate merely because its CRL endpoint is slow.

For recurring freshness, schedule the command with the system's existing task mechanism, using the same user or administrative account that owns the target store. A scheduler does not remove the need to review failures: CRLs can become unreachable, and a job that runs silently is not proof of fresh revocation data.