[Gpg4win-devel] X509 Root certificates and trusting them

Bernhard Reiter bernhard at intevation.de
Wed Sep 22 10:01:13 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.

[Forth edition]

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  
   konqueror info:/dirmngr/Installation
   http://gnupg.org/documentation/manuals/dirmngr/Installation.html
   
   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 
   already signed. 

   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 
   box.

   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

   Note that quite a few certificate authorities need the "relax" option
   because they fail to get some requirements right. So test everything later
   and if it does not work, try with "relax".
   
   References:  
     Existence of configuration file:
       info gnupg2 Installation
       konqueror info:/gnupg2/Installation
       http://gnupg.org/documentation/manuals/gnupg/Installation.html

     Format of trustlist.txt:
      info gnupg2 "Invoking GPG-AGENT" "Agent Configuration"
      konqueror info:/gnupg2/Agent Configuration
      http://gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html

   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
or reboot.
        
In general: If you wish to update all users' private configuration files,
you can try using Gnupg's helper application called 
  applygnupgdefaults
Documentation starts here:
  info gnupg2 "Helper Tools" applygnupgdefaults
  konqueror info:/gnupg2/applygnupgdefaults
  http://gnupg.org/documentation/manuals/gnupg/applygnupgdefaults.html

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.

Best,
Bernhard

-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100922/0be39518/attachment.pgp>


More information about the Gnupg-devel mailing list