Most likely the option enable-ocsp is active for gpgsm but Dirmngr’s OCSP feature has not been enabled using allow-ocsp in dirmngr.conf.
The far most common reason for this is that the environment variable
GPG_TTY has not been set correctly. Make sure that it has been
set to a real tty devce and not just to ‘/dev/tty’;
i.e. ‘GPG_TTY=tty’ is plainly wrong; what you want is
‘GPG_TTY=`tty`’ — note the back ticks. Also make sure that
this environment variable gets exported, that is you should follow up
the setting with an ‘export GPG_TTY’ (assuming a Bourne style
shell). Even for GUI based Pinentries; you should have set
GPG_TTY. See the section on installing the
on how to do it.
SSH has no way to tell the gpg-agent what terminal or X display it is running on. So when remotely logging into a box where a gpg-agent with SSH support is running, the pinentry will get popped up on whatever display the gpg-agent has been started. To solve this problem you may issue the command
echo UPDATESTARTUPTTY | gpg-connect-agent
and the next pinentry will pop up on your display or screen. However, you need to kill the running pinentry first because only one pinentry may be running at once. If you plan to use ssh on a new display you should issue the above command before invoking ssh or any other service making use of ssh.
I may happen that you have created a certificate request using
gpgsm but not yet received and imported the certificate from
the CA. However, you want to export the secret key to another machine
right now to import the certificate over there then. You can do this
with a little trick but it requires that you know the approximate time
you created the signing request. By running the command
ls -ltr ~/.gnupg/private-keys-v1.d
you get a listing of all private keys under control of
Pick the key which best matches the creation time and run the command
/usr/local/libexec/gpg-protect-tool --p12-export \ ~/.gnupg/private-keys-v1.d/foo >foo.p12
(Please adjust the path to
gpg-protect-tool to the appropriate
location). foo is the name of the key file you picked (it should
have the suffix .key). A Pinentry box will pop up and ask you
for the current passphrase of the key and a new passphrase to protect it
in the pkcs#12 file.
To import the created file on the machine you use this command:
/usr/local/libexec/gpg-protect-tool --p12-import --store foo.p12
You will be asked for the pkcs#12 passphrase and a new passphrase to protect the imported private key at its new location.
Note that there is no easy way to match existing certificates with stored private keys because some private keys are used for Secure Shell or other purposes and don’t have a corresponding certificate.
A common problem is that the root certificate misses the required
basicConstraints attribute and thus
gpgsm rejects this
certificate. An error message indicating “no value” is a sign for
such a certificate. You may use the
relax flag in
trustlist.txt to accept the certificate anyway. Note that the
fingerprint and this flag may only be added manually to
The signature is broken. You may try the option --extra-digest-algo SHA256 to workaround the problem. The number N is the internal algorithm identifier; for example 8 refers to SHA-256.
When running the W32 version of
gpg under Wine you may get
an error messages like:
gpg: fatal: WriteConsole failed: Access denied
The solution is to use the command
Some operations like gen-key really want to talk to the console directly
for increased security (for example to prevent the passphrase from
appearing on the screen). So, you should use
wine, which will launch a windows console that
implements those additional features.
For performance reasons the keyservers do not check the keys the same
gpg does. It may happen that the listing of keys
available on the keyservers shows keys with wrong user IDs or with user
Ids from other keys. If you try to import this key, the bad keys or bad
user ids won’t get imported, though. This is a bit unfortunate but we
can’t do anything about it without actually downloading the keys.