Next: 24. Using Sympa commands Up: Sympa Mailing Lists Management Software version Previous: 22. Using Sympa with LDAP Contents Index
Subsections

- 23.1 Signed message distribution
- 23.2 Use of S/MIME signature by Sympa itself
- 23.3 Use of S/MIME encryption
- 23.4 S/Sympa configuration
  - 23.4.1 Installation
  - 23.4.2 configuration in sympa.conf
  - 23.4.3 configuration to recognize S/MIME signatures
  - 23.4.4 distributing encrypted messages
- 23.5 Managing certificates with tasks
  - 23.5.1 chk_cert_expiration.daily.task model
  - 23.5.2 crl_update.daily.task model

#
23. Sympa with S/MIME and HTTPS

S/MIME is a cryptographic method for Mime messages based on X509 certificates. Before installing Sympa S/Mime features (which we call S/Sympa), you should be under no illusion about what the S stands for : ``S/MIME'' means ``Secure MIME''. That S certainly does not stand for ``Simple''.

The aim of this chapter is simply to describe what security level is provided by Sympa while using S/MIME messages, and how to configure Sympa for it. It is not intended to teach anyone what S/Mime is and why it is so complex ! RFCs numbers 2311, 2312, 2632, 2633 and 2634, along with a lot of literature about S/MIME, PKCS#7 and PKI is available on the Internet. Sympa 2.7 is the first version of Sympa to include S/MIME features as beta-testing features.

# 23.1 Signed message distribution

No action required. You probably imagine that any mailing list manager (or any mail forwarder) is compatible with S/MIME signatures, as long as it respects the MIME structure of incoming messages. You are right. Even Majordomo can distribute a signed message! As Sympa provides MIME compatibility, you don't need to do anything in order to allow subscribers to verify signed messages distributed through a list. This is not an issue at all, since any processe that distributes messages is compatible with end user signing processes. Sympa simply skips the message footer attachment (ref 15.11, page ) to prevent any body corruption which would break the signature.

#
23.2 Use of S/MIME signature by Sympa itself

Sympa is able to verify S/MIME signatures in order to apply S/MIME authentication methods for message handling. Currently, this feature is limited to the distribution process, and to any commands Sympa might find in the message body. The reasons for this restriction are related to current S/MIME usage. S/MIME signature structure is based on the encryption of a digest of the message. Most S/MIME agents do not include any part of the message headers in the message digest, so anyone can modify the message header without signature corruption! This is easy to do : for example, anyone can edit a signed message with their preferred message agent, modify whatever header they want (for example `Subject:` , `Date:` and `To:`, and redistribute the message to a list or to the robot without breaking the signature.

So Sympa cannot apply the S/MIME authentication method to a command parsed in the `Subject:` field of a message or via the `-subscribe` or `-unsubscribe` e-mail address.

# 23.3 Use of S/MIME encryption

S/Sympa is not an implementation of the ``S/MIME Symmetric Key Distribution'' internet draft. This sophisticated scheme is required for large lists with encryption. So, there is still some scope for future developments :)

We assume that S/Sympa distributes message as received, i.e. unencrypted when the list receives an unencrypted message, but otherwise encrypted.

In order to be able to send encrypted messages to a list, the sender needs to use the X509 certificate of the list. Sympa will send an encrypted message to each subscriber using the subscriber's certificate. To provide this feature, Sympa needs to manage one certificate for each list and one for each subscriber. This is available in Sympa version 2.8 and above.

# 23.4 S/Sympa configuration

##
23.4.1 Installation

The only requirement is OpenSSL (http://www.openssl.org) version 0.9.5a and above. OpenSSL is used by Sympa as an external plugin (like sendmail or postfix), so it must be installed with the appropriate access (x for sympa.sympa).

##
23.4.2 configuration in sympa.conf

S/Sympa configuration is very simple. If you are used to Apache SSL, you should not feel lost. If you are an OpenSSL guru, you will feel at home, and there may even be changes you will wish to suggest to us.

The basic requirement is to let Sympa know where to find the binary file for the OpenSSL program and the certificates of the trusted certificate authority. This is done using the optional parameters `openSSL` and `capath` and / or `cafile`.

- `openSSL` : the path for the OpenSSL binary file, usually `/usr/local/ssl/bin/openSSL`
- `cafile` : the path of a bundle of trusted ca certificates. The file `~/usr/local/sympa-os/bin/etc/cabundle.crt` included in Sympa distribution can be used.

  Both the `cafile` file and the `capath` directory should be shared with your Apache+mod_ssl configuration. This is useful for the S/Sympa web interface. Please refer to the OpenSSL documentation for details.

- `key_password` : the password used to protect all list private keys. xxxxxxx

##
23.4.3 configuration to recognize S/MIME signatures

Once `OpenSSL` has been installed, and `sympa.conf` configured, your S/Sympa is ready to use S/Mime signatures for any authentication operation. You simply need to use the appropriate authorization scenario for the operation you want to secure. (see 12, page ).

When receiving a message, Sympa applies the authorization scenario with the appropriate authentication method parameter. In most cases the authentication method is ```smtp`'', but in cases where the message is signed and the signature has been checked and matches the sender e-mail, Sympa applies the ```smime`'' authentication method.

It is vital to ensure that if the authorization scenario does not recognize this authentication method, the operation requested will be rejected. Consequently, authorization scenarios distributed prior to version 2.7 are not compatible with the OpenSSL configuration of Sympa. All standard authorization scenarios (those distributed with sympa) now include the `smime` method. The following example is named `send.private_smime`, and restricts sends to subscribers using an S/mime signature :

    title.us restricted to subscribers check smime signature
    title.fr limité aux abonnés, vérif de la signature smime

    is_subscriber([listname],[sender])             smime  -> do_it
    is_editor([listname],[sender])                 smime  -> do_it
    is_owner([listname],[sender])                  smime  -> do_it

It as also possible to mix various authentication methods in a single authorization scenario. The following example, `send.private_key`, requires either an md5 return key or an S/Mime signature :

    title.us restricted to subscribers with previous md5 authentication
    title.fr réservé aux abonnés avec authentification MD5 préalable

    is_subscriber([listname],[sender]) smtp          -> request_auth
    true()                             md5,smime     -> do_it

##
23.4.4 distributing encrypted messages

In this section we describe S/Sympa encryption features. The goal is to use S/MIME encryption for distribution of a message to subscribers whenever the message has been received encrypted from the sender.

Why is S/Sympa concerned by the S/MIME encryption distribution process ? It is because encryption is performed using the recipient X509 certificate, whereas the signature requires the sender's private key. Thus, an encrypted message can be read by the recipient only if he or she is the owner of the private key associated with the certificate. Consequently, the only way to encrypt a message for a list of recipients is to encrypt and send the message for each recipient. This is what S/Sympa does when distributing an encrypted message.

The S/Sympa encryption feature in the distribution process supposes that Sympa has received an encrypted message for some list. To be able to encrypt a message for a list, the sender must have some access to an X509 certificate for the list. So the first requirement is to install a certificate and a private key for the list. The mechanism whereby certificates are obtained and managed is complex. Current versions of S/Sympa assume that list certificates and private keys are installed by the listmaster using `/usr/local/sympa-os/bin/p12topem.pl` script. This script allows you to install a PKCS#12 bundle file containing a private key and a certificate using the appropriate format.

It is a good idea to have a look at the OpenCA (http://www.openssl.org) documentation and/or PKI providers' web documentation. You can use commercial certificates or home-made ones. Of course, the certificate must be approved for e-mail applications, and issued by one of the trusted CA's described in the `cafile` file or the `capath` Sympa configuration parameter.

The list private key must be installed in a file named `/usr/local/sympa-os/expl/mylist/private_key`. All the list private keys must be encrypted using a single password defined by the `password` parameter in `sympa.conf`.

### 23.4.4.1 Use of navigator to obtain X509 list certificates

In many cases e-mail X509 certificates are distributed via a web server and loaded into the browser using your mouse :) Mozilla or internet explorer allows certificates to be exported to a file.

Here is a way to install a certificat for a list:

- Get a list certificate is to obtain an personal e-mail certificate for the canonical list address in your browser as if it was your personal certificate,

- export the intended certificate it. The format used by Netscape is ``pkcs#12''. Copy this file to the list home directory.
- convert the pkcs#12 file into a pair of pem files : `cert.pem` and `private_key` using the `/usr/local/sympa-os/bin/p12topem.pl` script. Use `p12topem.pl -help` for details.
- be sure that `cert.pem` and `private_key` are owned by sympa with ``r'' access.
- As soon as a certificate is installed for a list, the list home page includes a new link to load the certificate to the user's browser, and the welcome message is signed by the list.

# 23.5 Managing certificates with tasks

You may automate the management of certificates with two global task models provided with Sympa. See 14.10, page to know more about tasks. Report to 6.12.4, page to configure your Sympa to use these facilities.

## 23.5.1 chk_cert_expiration.daily.task model

A task created with the model `chk_cert_expiration.daily.task` checks every day the expiration date of certificates stored in the `/usr/local/sympa-os/expl/X509-user-certs/` directory. The user is warned with the `daily_cert_expiration` template when his certificate has expired or is going to expire within three days.

## 23.5.2 crl_update.daily.task model

You may use the model `crl_update.daily.task` to create a task which daily updates the certificate revocation lists when needed.

Next: 24. Using Sympa commands Up: Sympa Mailing Lists Management Software version Previous: 22. Using Sympa with LDAP Contents Index