Dirmngr makes use of several directories when running in daemon mode: There are a few configuration files to control the operation of dirmngr. By default they may all be found in the current home directory (see option --homedir).
This is the standard configuration file read by
startup. It may contain any valid long option; the leading two dashes
may not be entered and the option may not be abbreviated. This file
is also read after a
SIGHUP however not all options will
actually have an effect. This default name may be changed on the
command line (see option --options). You should backup this file.
This directory should be filled with certificates of Root CAs you are trusting in checking the CRLs and signing OCSP Responses.
Usually these are the same certificates you use with the applications
making use of dirmngr. It is expected that each of these certificate
files contain exactly one DER encoded certificate in a file
with the suffix .crt or .der.
those certificates on startup and when given a SIGHUP. Certificates
which are not readable or do not make up a proper X.509 certificate
are ignored; see the log file for details.
Applications using dirmngr (e.g. gpgsm) can request these certificates to complete a trust chain in the same way as with the extra-certs directory (see below).
Note that for OCSP responses the certificate specified using the option --ocsp-signer is always considered valid to sign OCSP requests.
This directory may contain extra certificates which are preloaded into the internal cache on startup. Applications using dirmngr (e.g. gpgsm) can request cached certificates to complete a trust chain. This is convenient in cases you have a couple intermediate CA certificates or certificates usually used to sign OCSP responses. These certificates are first tried before going out to the net to look for them. These certificates must also be DER encoded and suffixed with .crt or .der.
This directory is used to store cached CRLs. The crls.d part will be created by dirmngr if it does not exists but you need to make sure that the upper directory exists.
Several options control the use of trusted certificates for TLS and CRLs. Here is an Overview on the use and origin of those Root CA certificates:
These System root certificates are used by: FIXME
The origin of the system provided certificates depends on the
platform. On Windows all certificates from the Windows System Stores
CA are used.
On other platforms the certificates are read from the first file found form this list: /etc/ssl/ca-bundle.pem, /etc/ssl/certs/ca-certificates.crt, /etc/pki/tls/cert.pem, /usr/local/share/certs/ca-root-nss.crt, /etc/ssl/cert.pem.
The GnuPG specific certificates stored in the directory /etc/gnupg/trusted-certs are only used to validate CRLs.
For accessing the OpenPGP keyservers the only certificates used are those set with the configuration option hkp-cacert.
This is usually only one certificate read from the file
INSTDIR/share/gnupg/gnupg/sks-keyservers.netCA.pem. If this
certificate exists it is used to access the special keyservers
hkps.pool.sks-keyservers.net (or hkps://keys.gnupg.net).
Please note that
gpgsm accepts Root CA certificates for its
own purposes only if they are listed in its file trustlist.txt.
dirmngr does not make use of this list - except FIXME.
To be able to see diagnostics it is often useful to put at least the following lines into the configuration file ~/gnupg/dirmngr.conf:
log-file ~/dirmngr.log verbose
You may want to check the log file to see whether all desired root CA certificates are correctly loaded.
To be able to perform OCSP requests you probably want to add the line:
To make sure that new options are read or that after the installation of a new GnuPG versions the right dirmngr version is running, you should kill an existing dirmngr so that a new instance is started as needed by the other components:
gpgconf --kill dirmngr
Direct interfaction with the dirmngr is possible by using the command
HELP at the prompt to see a list of commands and enter
HELP followed by a command name to get help on that command.