Refresh Mono Certificate Revocation Lists with crlupdate

A Mono app that suddenly refuses to validate a certificate is often just missing a fresh CRL, and crlupdate fixes that. It downloads missing or overdue certificate revocation lists (CRLs), first for the current user's certificate store and then, if you genuinely need it, for the machine store. Allow about fifteen minutes, plus whatever time the CRL servers take to answer.

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

1. Check the installed command

Start with read-only checks. None of these 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

2. Refresh the current user's store

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

$ crlupdate -v

• Exact output varies. The lines depend on the certificates in your store, their CRL distribution points, and how the network responds.
• A clean return does not mean full coverage. It only means the run completed; some certificates may still lack a reachable CRL server.
• Skip sudo here. Running as root selects root's user store, not the store belonging to the account that actually runs your Mono application.

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

Exit status 0 confirms the process completed successfully. It is not a report of how many CRLs actually changed, so keep the verbose output on hand whenever you are chasing 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. It is shared state, so a change here can affect multiple processes at once. Identify the service account and its certificate-store design first; never guess from the service name alone.

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

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

The # prompt marks a command that may need administrative privileges. It is not a reason to reach for sudo automatically: check the actual permissions and the account the consuming service runs under first.

4. Understand normal updates versus forced updates

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

-f forces downloads for every CRL associated with certificates in the selected store, even when their current lists are not due. This is a state-changing, network-dependent operation, so use it for a deliberate repair or investigation, not as a reflex the moment a verbose run looks too quiet:

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

The first line 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 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 failed CRL download can trace back to the certificate's distribution point, DNS, a proxy, TLS validation or local store permissions. Capture the verbose output and the exit status together:

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

• That status is only an example of failure, not a promise every release uses that exact number for every cause. Use the text your installed build prints to find the failing certificate or endpoint; the manual documents the options but not a complete portable error-code table.
• User store works, machine store does not? Compare the effective account and store permissions before changing anything.
• Both stores fail? Test the relevant CRL URLs and proxy policy with your normal network diagnostic process. Do not disable certificate verification or swap a certificate just because its CRL endpoint is slow.

For recurring freshness, schedule the command with your 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 go unreachable, and a job that runs silently is no proof of fresh revocation data.