Configure and Check dirmngr Without Losing Track of Its Daemon

You will configure the per-user GnuPG network daemon, check which instance is answering, and reload or replace it without guessing which process owns the socket. The examples use dirmngr 2.4.4 from Ubuntu package dirmngr 2.4.4-2ubuntu17.6. Allow about fifteen minutes for a normal setup, or longer if a proxy or certificate service is involved.

dirmngr is normally started on demand by GnuPG tools. It handles OpenPGP keyserver access and also supports CRL, certificate and OCSP network operations for GnuPG's X.509 tools. You usually manage it through gpgconf and inspect it through gpg-connect-agent, rather than launching a second system daemon by hand.

1. Check the installed program

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

$ command -v dirmngr
/usr/bin/dirmngr
$ dirmngr --version
dirmngr (GnuPG) 2.4.4
$ dpkg-query -W -f='${Package} ${Version}\n' dirmngr
dirmngr 2.4.4-2ubuntu17.6

The package version and the program version normally agree, but record both when diagnosing a distribution-specific issue. The default per-user home is ~/.gnupg, unless GNUPGHOME is set. Dirmngr stores its configuration and runtime data under that GnuPG home.

2. Inspect the current daemon

Ask gpgconf to start the daemon on demand, then query it. Starting the user's own on-demand daemon is an ordinary operation; it does not require sudo:

$ gpgconf --launch dirmngr
$ gpg-connect-agent --dirmngr 'GETINFO version' /bye
D 2.4.4
OK
$ gpg-connect-agent --dirmngr 'GETINFO socket_name' /bye
D /run/user/1004/gnupg/S.dirmngr
OK

Your socket path will contain your user ID, not 1004. The useful checkpoint is the final OK. If the version is not the one you expect, do not edit configuration yet: an already-running daemon may still be serving requests.

3. Set a keyserver deliberately

Dirmngr's Debian configuration reports hkps://keys.openpgp.org as the built-in keyserver on this installation. Make an explicit choice only when your environment needs one. A keyserver URI is network-sensitive configuration, so use a host approved by your organisation and prefer TLS:

$ install -d -m 700 "$GNUPGHOME" 2>/dev/null || install -d -m 700 "$HOME/.gnupg"
$ printf '%s\n' 'keyserver hkps://keys.openpgp.org' >> "$HOME/.gnupg/dirmngr.conf"

The first command is optional if the directory already exists. Do not copy it blindly when GNUPGHOME is set: in that case, edit $GNUPGHOME/dirmngr.conf instead. The configuration file uses option names without the leading two dashes, so write keyserver, not --keyserver.

Before appending to a real configuration file, inspect it to avoid duplicate or contradictory settings:

$ test -f "$HOME/.gnupg/dirmngr.conf" && sed -n '1,160p' "$HOME/.gnupg/dirmngr.conf"
$ gpgconf --list-options dirmngr | grep '^keyserver:'
keyserver:16:0:use keyserver at URL:1:1:URL:"hkps%3a//keys.openpgp.org::

If you appended the wrong line, remove that exact line with a text editor or make a dated backup first and restore it. Do not use a broad search-and-replace across all GnuPG files.

4. Reload the configuration

Reload the existing user daemon through gpgconf:

$ gpgconf --reload dirmngr
$ gpg-connect-agent --dirmngr 'GETINFO version' /bye
D 2.4.4
OK

A reload rereads dirmngr.conf and refreshes cached CRLs and certificates, but the manual warns that not every option takes effect immediately. Options such as the LDAP server list file are not reread on reload, while --ldapserver entries are. If you changed a setting that still appears stale, stop the user daemon so GnuPG can start a fresh one:

$ gpgconf --kill dirmngr
$ gpgconf --launch dirmngr
$ gpg-connect-agent --dirmngr 'GETINFO version' /bye
D 2.4.4
OK

This interrupts dirmngr requests owned by your user. It does not remove your keys or configuration, but a command currently waiting for network access may fail and need to be retried. Do not use sudo gpgconf for a per-user daemon: that targets root's GnuPG context instead.

5. Add diagnostics without changing network policy

When a keyserver or certificate request fails, enable a log file and verbosity temporarily in dirmngr.conf:

log-file ~/.gnupg/dirmngr.log
verbose

Then reload or kill and relaunch the daemon, reproduce one failing request, and read the log:

$ gpgconf --reload dirmngr
$ tail -n 80 "$HOME/.gnupg/dirmngr.log"
$ gpgconf --kill dirmngr

Logs can contain host names and certificate details. Treat them as operational data and do not paste them into a public issue without review. Remove verbose and log-file when the investigation ends, then reload again. Leaving verbose logging enabled makes later failures harder to find and can grow the file indefinitely.

6. Separate keyserver problems from daemon problems

Use the dirmngr Assuan interface to inspect its current keyserver session. This is diagnostic and does not fetch or publish a key:

$ gpg-connect-agent --dirmngr 'KEYSERVER' /bye
D hkps://keys.openpgp.org
OK
$ gpg-connect-agent --dirmngr 'help keyserver' /bye
# KEYSERVER [<options>] [<uri>|<host>]
OK

If this returns OK but a key operation fails, investigate DNS, proxy, TLS trust or the selected keyserver rather than repeatedly restarting dirmngr. The daemon can honour the http_proxy environment setting when proxy honouring is configured, or use an explicit HTTP proxy. A proxy setting is a security boundary: verify where it sends traffic before adding it.

Do not enable add-servers as a generic fix for certificate failures. The manual warns that it can add arbitrary LDAP servers discovered from certificate distribution points, leak searches and create denial-of-service exposure. Likewise, OCSP requests are rejected by default for privacy reasons; enable allow-ocsp only when the application and trust policy require it.