[Gpg4win-devel] X509 Root certificates and trusting them
bernhard at intevation.de
Thu Jul 29 11:33:03 CEST 2010
Am Freitag, 21. Mai 2010 12:03:22 schrieb Bernhard Reiter:
> The recommended way for a
> production X509 /CMS system is that a list of trusted X509 root
> certificates is maintained by the administrator of the system
> directly for dirmngr and possibly the global gpgsm.
For gpgsm to be able to use certificates,
you need to have the full validated chain of certificates.
Especially for the root certificate, the person administrating
the machines (e.g. you) must ensure four conditions are given.
(Paths examples are for GNU systems,
the paths will be different for Mac OS or Windows.)
a) You need to have the root certificate and be sure that the file you have
is really the root certificate you would like to trust. You need to do this
best at installation time, because later - in the heat of the moment -
users will go along with everthing unchecked just to get the task done.
b.1) Make sure dirmngr trusts the root certificate.
info dirmngr Installation
In short, recommended is to use the system dirmngr,
place the root certification file in .der format
in /etc/dirmngr/trusted-certs and restart the dirmngr service.
b.2) Current revocation status information must be available.
gpgsm will ask dirmngr to validate each certificate.
As administrator you need to make sure that dirmngr can do that check.
Usually certificates contain information where to get the revocation list
via http or ldap. So dirmngr should be able to do http and ldap calls to
the internet. Secure connections are not necessary as revocation info is
You can tune dirmngr to use proxies or always ask specific servers
via ldap. There are a number of other ways, like OCSP, to get revocation
information. Too much to list them here. With sane certificate authorities
and network settings it will just work with the revocation lists out of the
If you need to trouble shoot, you can turn off checking of revocation
information for a moment to verify that this is the problem. Leaving this
off for production will degrade security significantly.
Users should have "prefer-system-dirmngr" in their local
gpgsm.conf (Usually ~/.gnupg/gpgsm.conf).
So that the system dirmngr is asked all the time.
c) Make sure gpg-agent trusts the root certificate
Recommended way is to do this system wide:
c.1) Place the right line in /etc/gnupg/trustlist.txt
Existence of configuration file:
info gnupg2 Installation
Format of trustlist.txt:
info gnupg2 "Invoking GPG-AGENT" "Agent Configuration"
konqueror info:/gnupg2/Agent Configuration
c.2) Make sure all users either
* have no personal trustlist.txt or
* have the option "include-default" in it.
The file will usually searched at ~/.gnupg/trustlist.txt.
I guess all gpg-agents will need a kick after the trustlist.txt change.
Try sending a SIGHUP to all gpg-agent processes, e.g.
pkill -SIGHUP gpg-agent
In general: If you wish to update all users' private configuration files,
you can try using Gnupg's helper application called
Documentation starts here:
info gnupg2 "Helper Tools" applygnupgdefaults
Hints for reading the documentation:
Using the documentation of your installed version is preferred,
because it usually is most correct.
Use "info" on the commandline, if you are familiar with it.
It will be installed on many GNU systems. There are other exotic texinfo
console viewers of course like tkman or pinfo.
If you have konqueror installed using "info:gnupg2" as URL will also work.
Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html
which on Debian Lenny comes with the kdebase-kio-plugins package.
This is my prefered method.
Managing Director - Owner: www.intevation.net (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel