We can also provide
paid support
for PGP/GPG installation, configuration and other issues not included in the limited free support, at rates of
$100 US/hour
(each started hour charged as full). Setting up a PGP/GPG account on a server with properly installed PGP would typically take 1 hour. Installing of GnuPG (freeware under GNU license) or PGP (if you have a valid license), would typically take 1-3 hours on servers without specific problems.
top
Known Limitations and Bugs (
read "Features"
)
-
MmPGP does not work on
Windows
server platforms (NT Empresa, Mia). PS: All client platforms with PGP or GPG are supported.
-
Fixed in MvPGP Lib v 0.124
:
With some versions of local-side PGP interfaces, in the notification after the decryption, the dollar sign and few other special characters may appear prepended with a
backslash
. It may slightly distort the column aligning.
-
Some messages in the installation are not yet localized to German - currently available in English only
top
Frequently Asked Questions
What is PGP and GPG?
Encryption programs. See more at the
art0038.htm
What is
~/
?
In Unix
~/
stands for the user home directory. It means the directory where all your files are located - it may contain folders keeping your web documents, miva data directory and many other files. Usually and correctly it should not be accessible from the web by a browser. Typically, on many systems it is equivalent to
/home/yourloginname/
How to initialize an already installed PGP or GnuPG?
Please refer to the PGP/GPG vendor's documentation for details. Often the following two steps would be enough to initialize a properly installed PGP or GnuPG if MvPGP/MmPGP is unable to do it for you:
-
Create a
.pgp
(for PGP) or
.gnupg
(for GNU Privacy Guard) directory in the server home directory (typically
/home/username/.pgp
or
/home/username/.gnupg
)
-
Generate a secret keypair - in a Telnet session type:
pgp -kg
(PGP), resp.
gpg --gen-key
(GnuPG) and follow the prompts.
How do I import my public keys into the server's key ring?
Preferably use the MvPGP/MmPGP interface for doing so. You can do it from the shell too:
-
On your local machine export your public key (
not
the private one!) to a file.
-
Upload the file to your
~/.pgp
(resp. the
~/.gnupg
) directory on the server.
-
Type
pgp -ka "the key file name"
(PGP),
resp.
gpg --import "the key file name"
(GnuPG)
-
Type
pgp -ks "key's e-mail address"
(PGP),
resp.
gpg --sign-key "key's e-mail address"
(GnuPG) to sign the imported key.
Alternatively you may import a key from a key server. Please refer to the PGP/GPG vendor's documentation for detailed explanation.
Why the imported keys do not appear in MvPGP/MmPGP?
See also the
troubleshoting
section below. There are several possible reasons:
-
If you successfully imported the key manually in a shell session (
Telnet
or
SSH
), then, most probably, your server uses other user ID (and therefore also other PGP/GPG configuration and keyrings) for cgi scripts than your own
uid
used in a shell sessions.
-
If you attemped to import a key with the MvPGP/MmPGP interface, then the PGP home directory is not properly set. It must be either inside of the original user home directory of the
uid
used by the web server when calling cgi scripts or it must be a subdirectory of the
mvpgp
(resp.
mmpgp
) directory in your own Miva data directory.
-
The key was not a valid
public
key or is not compatible with the PGP/GnuPG version on your server. Check also the paragraph
"Unsupported packet format..."
below.
-
You imported the key from a public server, but it was down, or you did not use the 8 bytes long hexadecimal user ID from the key's properties
Why I am getting:
"gpg: Warning: using insecure memory!"
(GnuPGP)?
It means that GPG uses a portion of operating memory possibly vulnerable against attacks from people having access to the machine (not visitors from the web). Although it is not a too serious threat, you or your system administrator should change the GPG binary permissions as follows:
chmod +s /usr/local/bin/gnupg
Why I am getting:
"Unsupported packet format - you need a newer version of PGP for this file"
(PGP 2.6.x)?
On your local PC (with the target keys), create and export a key with
RSA Legacy
algorithm (resp.
RSA
if no
RSA Legacy
available) instead of
DH/DSS
.
top
Troubleshooting
In case of troubles, before contacting the support, please be sure to:
-
read the
FAQ
-
check the
changelog
and
update
the module to the latest version
-
read
known limitation and bugs
Fixing Installation Problems
There is only a blank page in the MmPGP Admin screen in Order Fulfillment Confiuration
Please install the MvPGP library manually: save the
source
of the library to a file named
mvpgp.mv
, create a directory
/mvpgp/
in your public directory (Miva Script directory) and upload the mvpgp.mv file there through FTP. Then run the script through your browser to install the library - call
http://yourdomain.com/mvpvg/mvpgp.mv
.
'Cgi-bin directory not found!'
(MER-PGP-00008)
During the installation process, MvPGP/MmPGP needs to be able to create scripts in the currently active cgi-bin directory. It means that this directory must be accessible from either the Mva Script or the Miva Data directory root. If the installtion routine does not find the paths to the cgi-bin automatically, you need to enter the path, relative to either the Miva Data or the Miva Script directory, manually.
It does not make any sense to create a new cgi-bin directory (otherwise MvPGP/MmPGP would create it itself, of course). Only that cgi-bin directory that is assigned as ScriptAlias in the Apache configuration file (or equivalent on other web servers), may be used.
If the cgi-bin is parallel to both Miva Data and Miva Script directories (and nowhere overlapping with any of them), there are still other possibilities to install MvPGP/MmPGP. Try one or more of the following instructions:
-
Create a symbolic link manually within your Miva Data or Script directory, linked to the original cgi-bin. In the same time, you have to change the Miva configuration to accept symbolic links (
securityoption=15
- disabled by default). After completing the installation you should remove the symbolic link and reset the Miva configuration to the original state, so everything would be as safe as before again.
-
Temporarily change the ScriptAlias directive for your domain in the
httpd.conf
to point to a temporary cgi-bin directory within your Miva Script directory. After completing the installation sucesfully, copy the mvpgp.cgi (resp. the mmpgp.cgi) to the original cgi-bin directory, reset the httpd.conf to the orginal state and remove the temporary cgi-bin.
-
If you are using
GnuPG
on the server side, you may
download
the
mvpgp.cgi
shell script and install it in your
cgi-bin
. Set its permissions to
755
and run the mvpgp.mv installation directly from your browser in this way:
http://yourdomain.com/mvpgp/mvpgp.mv?MVP_Cybrhost=1
'Miva Data Directory not found!'
One of possible reasons of this error message is a different user ID (
uid
) used for the Miva engine (usually the account owner's uid) and another one for the web server (often 'nobody' or 'www' with Apache without cgi wrapper like suexec). Another reason may be use of other than the default name for your Miva Data directory. The most secure way, is entering the full (absolute) path to your Miva Data directory. If you are unsure about the correct path, log in with Telnet, go to your Miva Data directory (e.g.
'cd htsdata'
or
'cd mivadata'
; on some systems the Mivadata may be identical with the user root dir) and type
pwd
to see the full path. Here are few examples:
/home/accountName/htsdata/
(e.g. at CI Host)
/home/sites/site156/mivadata/
(e.g. at Cybrmall)
'No public keys!'
Most evident reason is that you have not imported any target public keys into your key ring. If you did it already (whether manually in Telnet/SSH or through the MvPGP/MmPGP interface), then a different user ID (uid) for CGI scripts and for Miva scripts could be the reason. Web servers (like Apache) sometimes use a special
uid
for calling documents and CGI scripts - often
'nobody'
or
'www'
. When there are respective user directories (e.g.
/home/nobody
), MvPGP/MmPGP should be able to work with the default
'~/.gnupg'
(resp.
'~/.pgp'
), but if there is no such directory on the system, you have to enter it manually. If the default dir does not work, a directory within the MvPGP/MmPGP subdirectory in the Miva Data dir should be used (see the paragraph above for ways to find out the path on your system):
/home/accountName/htsdata/mvpgp/.pgp/
(e.g. at CI Host)
/home/sites/site156/mivadata/mvpgp/.pgp/
(e.g. at Cybrmall)
(replace the
mvpgp
with
mmpgp
when installing a Merchant PGP module instead of the plain MvPGP library)
Enter the new location for the PGP/GPG home directory and try to import a key through the MvPGP/MmPGP interface.
NOTE:
MvPGP/MmPGP always tries to create the directory with the web server's
uid
and you may not be able to delete it from within a Telnet/SSH session, unless you have root access to the server. The directory may be removed with a cgi script in your cgi-bin called from a browser:
#!/bin/sh
echo "Content-Type: text/plain"
echo ""
rm -Rf /home/sites/site156/mivadata/mvpgp/.pgp/
exit 0
Replace the path with your real path to the PGP directory. Set its permissions to
755
. If you named the file
delpgp.cgi
, you would call it from browser in this way:
http://www.yourdomain/cgi-bin/delpgp.cgi
Remove the script after using it to avoid its abuse.
top
Security Notes
When using the MvPGP library or the MmPGP module, you should be aware of certain facts regarding the security.
You should disable access to the mvpgp.mv script to avoid access to it by by unauthorized visitors. Normally it is enough to disable both, the configuration listing and the test with selecting the '
hide
' checkboxes on the mvpgp.mv page. You may additionally restrict the access to the file from the web totally in the Apache's
.htaccess
configuration file in this way:
<Files "mvpgp.mv">
Order Deny,Allow
Deny from all
</Files>
Because of the location of the PGP/GnuPG configuration and key ring files on a public server, you should not trust the encrypted e-mail comming from the server. Anybody being able to break into your server, would be able to send e-mail using your PGP/GPG configuration and your secret keys. MvPGP/MmPGP in the recent version does not install any secret keys and if you do it manually, you should never use the same passphrases as you use for your usual encryption. Keep on mind that if somebody gained access to your private keys on the server, theoretically he might be able do crack then using brute force. There is no risk, if the secret key is used just on that server and never used for signing or exporting trusts to other keys. MvPGP/MmPGP does not use the secrete keys at all, so you may remove them from the keyring, or use just a dummy secret keys. MvPGP/MmPGP encrypts messages with the addressee's public keys only and do
not
sign them with the server's secret key.
MvPGP/MmPGP on systems with GnuPG uses the option
--always-trust
for any imported keys. This was made to simplify the automated installation procedure, but if you prefer signing all imported keys manually, please edit the
mvpgp.cgi
(resp. the
mmpgp.cgi
) in your cgi-bin directory and remove any instance of the
--always-trust
option. It brings you more security, because every new key must be then signed using the server's passphrase manually from the shell (SSH/Telnet).
top
Wish List
-
MmPGP for Miva Empresa NT
top
Change Log
top
Some Useful Links
MvPGP Library
The GNU Privacy Guard
GnuPG in an automated environment
OpenPGP.org
RFC 2440: OpenPGP Message Format
RFC 1991: PGP Message Exchange Formats
MIT's PGP Freeware
PGP Freeware for different OS at PGP international
The International PGP Home Page
PGP Home Page
Gnu Privacy Guard Mini Howto
VISA Security Requirements
top
