• NAME
• CONFIGURATION
  • %SMIME
    • OpenSSL
    • Keyring
    • CAPath
    • AcceptUntrustedCAs
    • Passphrase
    • OtherCertificatesToSend
    • CheckCRL
    • CheckOCSP
    • CheckRevocationDownloadTimeout
  • 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',
            'another.queue.address@example.com' => {
                Encryption => 'passphrase for encryption certificate',
                Signing    => 'passphrase for signing certificate',
            },
            '' => 'fallback',
        },
        OtherCertificatesToSend => '/opt/rt5/var/data/smime/other-certs.pem',
        CheckCRL => 0,
        CheckOCSP => 0,
        CheckRevocationDownloadTimeout => 30,
    );

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.

OtherCertificatesToSend

OtherCertificatesToSend is a path to a PEM-formatted certificate file. Certificates in the file will be include in outgoing signed emails.

Depending on use cases, you might need to include a chain of certificates so receiving agents can verify. CA could also be included here.

CheckCRL

A boolean option that determines whether or not we attempt to check if a certificate is revoked by downloading a CRL. The default value is false (do not check). Additionally, if AcceptUntrustedCAs is true, RT will never download a CRL or check an OCSP URL for a certificate signed by an untrusted CA.

CheckOCSP

A boolean option that determines whether or not we check if a certificate is revoked by checking the OCSP URL (if any). The default value is false.

CheckRevocationDownloadTimeout

Timeout in seconds for downloading a CRL or issuer certificate for OCSP checking. The default is 30 seconds.

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.

For addresses that have separate certificates for encryption/decryption and signing, the PEM files need to be named like email.address@example.com.encryption.pem and email.address@example.com.signing.pem, respectively.

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.

← Back to index