• NAME
• CONFIGURATION
  • %SMIME
    • OpenSSL
    • Keyring
    • CAPath
    • AcceptUntrustedCAs
    • Passphrase
  • Keyring configuration

NAME

RT::Crypt::SMIME - encrypt/decrypt and sign/verify email messages with the SMIME

CONFIGURATION

You should start from reading RT::Crypt.

%SMIME

    Set( %SMIME,
        Enable => 1,
        OpenSSL => '/usr/bin/openssl',
        Keyring => '/opt/rt5/var/data/smime',
        CAPath  => '/opt/rt5/var/data/smime/signing-ca.pem',
        Passphrase => {
            'queue.address@example.com' => 'passphrase',
            '' => 'fallback',
        },
    );

OpenSSL

Path to openssl executable.

Keyring

Path to directory with keys and certificates for queues. Key and certificates should be stored in a PEM file named, e.g., email.address@example.com.pem. See "Keyring configuration".

CAPath

CAPath should be set to either a PEM-formatted certificate of a single signing certificate authority, or a directory of such (including hash symlinks as created by the openssl tool c_rehash). Only SMIME certificates signed by these certificate authorities will be treated as valid signatures. If left unset (and AcceptUntrustedCAs is unset, as it is by default), no signatures will be marked as valid!

AcceptUntrustedCAs

Allows arbitrary SMIME certificates, no matter their signing entities. Such mails will be marked as untrusted, but signed; CAPath will be used to mark which mails are signed by trusted certificate authorities. This configuration is generally insecure, as it allows the possibility of accepting forged mail signed by an untrusted certificate authority.

Setting this option also allows encryption to users with certificates created by untrusted CAs.

Passphrase

Passphrase may be set to a scalar (to use for all keys), an anonymous function, or a hash (to look up by address). If the hash is used, the '' key is used as a default.

Keyring configuration

RT looks for keys in the directory configured in the "Keyring" option of the "%SMIME" in RT_Config. While public certificates are also stored on users, private SSL keys are only loaded from disk. Keys and certificates should be concatenated, in in PEM format, in files named email.address@example.com.pem, for example.

These files need be readable by the web server user which is running RT's web interface; however, if you are running cronjobs or other utilities that access RT directly via API, and may generate encrypted/signed notifications, then the users you execute these scripts under must have access too.

The keyring on disk will be checked before the user with the email address is examined. If the file exists, it will be used in preference to the certificate on the user.