Sponsored Content
Special Forums News, Links, Events and Announcements Software Releases - RSS News Z1 SecureMail Gateway 3.1 (Default branch) Post 302188086 by Linux Bot on Tuesday 22nd of April 2008 03:30:07 PM
Old 04-22-2008
Z1 SecureMail Gateway 3.1 (Default branch)

Image Z1 SecureMail Gateway is a central, server-based software solution which provides encryption and digital signatures (PGP and S/MIME) for the entire email traffic of an organization. It works with organizational certificates and certificates for individual users, groups or organizational units. It provides its services transparently to end users. Z1 SecureMail Gateway automatically finds certificates of external users or companies via the Internet. Secure email traffic to customers, suppliers, and partners is easily established, no matter whether or not they also deploy Z1 SecureMail Gateway. Evaluation packages for Red Hat and SuSE as well as SUN Solaris are available for download. License: Other/Proprietary License with Free Trial Changes:
An enhanced new group feature was provided. Groups may contain single members (e-mail) or domains (wildcard), and policies can now be assigned to groups. The usability of the Admin Webclient was improved. A new user confirmation feature was introduced to protect outgoing sensitive operations like signing e-mail. New user commands were added for sending reports. PKCS#7 attachment validation was implmented, which verifies signed attachments and generates validation reports similar to GDPDU. An "e-mail-copy-to" feature that duplicates all incoming e-mails and sends them to a specific SMTP server (e.g. e-mail archive) was added.Image

More...
 

We Also Found This Discussion For You

1. UNIX for Beginners Questions & Answers

Inconsistency between RedHat 6.5 global gateway and single gateway leads to loss of default gateway

Dear friends I use RedHat 6.5, which sets the gateway in the configuration file / etc / sysconfig / network as GATEWAY = 192.168.1.26, and the gateway in the configuration file / etc / sysconfig / network-scripts / ifcfg-eth11 as GATEWAY = 192.168.1.256. The two gateways are different.... (6 Replies)
Discussion started by: tanpeng
6 Replies
lprng_certs(1)							lprng_certs command						    lprng_certs(1)

NAME
lprng_certs - lprng SSL certificate management SYNOPSIS
lprng_certs option Options: init - make directory structure newca - make new root CA defaults - set new default values for certs gen - generate user, server, or signing cert index [dir] - index cert files verify [cert] - verify cert file encrypt keyfile - set or change keyfile password DESCRIPTION
The lprng_certs program is used to manage SSL certificates for the LPRng software. There SSL certificate structure consists of a hierarchy of certificates. The LPRng software assumes that the following types of certificates will be used: CA or root A top level or self-signed certificate. signing A certificate that can be used to sign other certificates. This is signed by the root CA or another signing certificate. user A certificate used by a user to identify themselves to the lpd server. server A certificate used by the lpd server to identify themselves to the user or other lpd servers. Signing Certificates All of the signing certificates, including the root certificate (root CA), /etc/lprng/ssl.ca/ca.crt, are in the same directory as the root CA file. Alternately, all of the signing certs can be concatenated and put into a single file, which by convention is assumed to have the same name as the root CA file, /etc/lprng/ssl.ca/ca.crt. The ssl_ca_file, ssl_ca_path, and ssl_ca_key printcap and configuration options can be used to specify the locations of the root CA files, a directory containing the signing certificate files, and the private key file for the root CA file respectively. The root certificate (root CA file) /etc/lprng/ssl.ca/ca.crt has a private key file /etc/lprng/ssl.ca/ca.key as well. By convention, the private keys for the other signing certificate files are stored in the certificate file. The OpenSSL software requires that this directory also contain a set of hash files which are, in effect, links to these files. By default, all signing certificates are assumed to be in the same directory as the root certificate. Server Certificates The certificate used by the lpd server are kept in another directory. These files do not need to have hash links to them. By convention, the private keys for these certificate files are stored in the certificate file. The server certificate file is specified by the ssl_server_cert and has the default value /etc/lprng/ssl.server/server.crt. This file contains the cert and private key. The server cer- tificate password file is specified by the ssl_server_password option with the default value and contains the password used to decrypt the servers private key and use it for authentication. This key file should be read only by the lpd server. User Certificates The certificates used by users are kept in a separate directory in the users home directory. By convention, the private keys for these certificate files are stored in the certificate file. The user certificate file is specified by the LPR_SSL_FILE environment variable, otherwise the ${HOME}/.lpr/client.crt is used. The pass- word is taken from the file specified by the LPR_SSL_PASSWORD environment variable, otherwise the ${HOME}/.lpr/client.pwd file is read. USING LPRNG_CERTS The organization of the SSL certificates used by LPRng is similar to that used by other programs such as the Apache mod_ssl support. The lprng_certs program is used to create the directory structure, create certificates for the root CA, signing, user and servers. In order to make management simple, the following support is provided. lprng_certs init This command creates the directories used by the lpd server. It is useful when setting up a new lpd server. lprng_certs newca This command creates a self-signed certificate, suitable for use as a root CA certificate. It also sets up a set of default values for other certificate creation. lprng_certs defaults This command is used to modify the set of default values. The default values are listed and should be self-explanatory, except for the value of the signer certificate. By default, the root CA can be used to sign certificates. However, a signing certificate can be used as well. This allows delegation of signing authority without compromising the security of the root CA. lprng_certs gen This is used to generate a user, server, or signing certificate. lprng_certs index This is used to create the indexes for the signing certificates. lprng_certs verify [cert] This checks the certificate file using the Openssl openssl verify command. lprng_certs encrypt keyfile This removes all key information from the key file, reencrypts the key information, and the puts the encrypted key information in the file. LPRng OPTIONS Option Purpose ssl_ca_path directory holding the SSL signing certs ssl_ca_file file holding the root CA or all SSL signing certs ssl_server_cert cert file for the server ssl_server_password file containing password for server server ${HOME}/.lpr/client.crt client certificate file ${HOME}/.lpr/client.pwd client certificate private key password ENVIRONMENT VARIABLES
LPR_SSL_FILE client certificate file LPR_SSL_PASSWORD client certificate private key password EXIT STATUS
The following exit values are returned: zero (0) Successful completion. non-zero (!=0) An error occurred. SEE ALSO
lpd.conf(5), lpc(8), lpd(8), checkpc(8), lpr(1), lpq(1), lprm(1), printcap(5), lpd.conf(5), pr(1), lprng_certs(1), lprng_index_certs(1). AUTHOR
Patrick Powell <papowell@lprng.com>. HISTORY
LPRng is a enhanced printer spooler system with functionality similar to the Berkeley LPR software. The LPRng developer mailing list is lprng-devel@lists.sourceforge.net; subscribe by visiting https://lists.sourceforge.net/lists/listinfo/lprng-devel or sending mail to lprng- request@lists.sourceforge.net with the word subscribe in the body. The software is available via http://lprng.sourceforge.net LPRng 2006-12-09 lprng_certs(1)
All times are GMT -4. The time now is 01:13 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy