2009 Jul 18 - Sat
Debian Lenny with Sendmail, Dovecot, MailScanner, SpamAssassin: Part 3
In part two of this series, I started into the installation of the Dovecot IMAP service. The IMAP
serivce can use validation and encryption through the use of SSL/TLS services. SSL/TLS services require
the use of Certificates signed through a Certificate Authority. Many installation directions provide information for
using the simple expedient of self-signed certificates. As some of these services I'm building are quasi-public,
I wanted to go through the exercise of getting my certificates signed through a Certificate Authority.
As such, I was side-tracked into doing some research to come up with two intermediate articles:
I'm going to step back to my SendMail install, and get a certificate installed in order to
utilize SendMail's TLS based verification and encryption capabilities.
In the /etc/mail/sendmail.mc file, the following needs to be available (I've enabled AUTH as well):
include(`/etc/mail/sasl/sasl.m4')dnl
include(`/etc/mail/tls/starttls.m4')dnl
Don't put these lines in the submit.mc file as they will cause permission errors.
For configuring AUTH (SASL2), edit /etc/default/saslauthd and make sure 'MECHANISMS="pam"' is included and then
start the service: /etc/init.d/saslauthd start. Shell users should now be able to authenticate, otherwise use
/usr/sbin/saslpasswd2 to add users.
You cancheck in /etc/mail/tls to see various self-signed certificates which have already been created and linked within
the configuration file /etc/mail/tls/starttls.m4. The various settings can be changed to match the new certificate.
I changed the line with confCACERT to match my StartCom CA found in /etc/ssl/certs. I had placed
my new server key and cert in /etc/ssl/private, and in sendmail.mc, updated confSERVER_CERT and confSERVER_KEY to match.
Once the certificates are properly installed and SendMail restarted, it can be tested by connecting to telneting
to port 25, running 'ehlo localhost' and looking for a line with '250-STARTTLS'. If it is there, all is well.
I found the page at
SMTP STARTTLS in sendmail/Secure Switch
to help somewhat in building the scenario.
For testing the STARTTLS capability, one can use the one of the following openssl commands (the first works better than the second):
openssl s_client -starttls smtp -connect localhost:25
openssl s_client -ssl3 -state -debug -msg -connect localhost:25
For other OpenSSL s_client command line parameters, visit:
s_client man page.
At one point, I was getting errors in sendmail logs with:
STARTTLS=read: 12080:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284:
STARTTLS: read error=generic SSL error (-1), errno=104,
get_error=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number, retry=1, ssl_err=1
I think these are permissions related depending upon privleges of certificate files and
the username under which sendmail is running. Sendmail is now running under root and no longer
has these problems. The errors magically disappeared during some restart so I can't confirm this
for sure. ... further information: the errors happen when running the 'openssl s_client -ssl3 -state -debug -msg -connect localhost:25'
command, but not the 'openssl s_client -starttls smtp -connect localhost:25'. I havn't spent the time
to determine why yet.
I was also getting errors like:
STARTTLS=client: file /etc/ssl/private/sub.class1.server.ca.pem unsafe: Permission denied
STARTTLS=client, error: load verify locs /etc/ssl/certs, /etc/ssl/private/sub.class1.server.ca.pem failed: 0
These errors went away by taking the starttls.m4 and sasl.m4 macros out of submit.mc.
|
