Using certificates with sendmail allows you to encrypt incoming and outgoing traffic, providing the remote MTA also support TLS. It also allows you to use the authentication mechanism EXTERNAL for various purposes including relaying when a TLS link is successfully negotiated.
 | Useful Information
Due to Internet mail architecture (SMTP), the encrypted channel is only between your host and the first hop remote host (MTA relay). TLS (partially) protects your host against eavesdropping, but not the full exchange path between sender host and recipient host, the additional hops are not under your control. Hopefully you might have a complete encrypted path. |
You need to attach certificates and related stuff to the sendmail service. That is you have to perform the following steps:
- Obtain a certificate for your host
- Check the DNS naming scheme of your hosts and services
- Adopt an external naming scheme, or define one for your OSI names osiNames
- Check your host name, it defaults to your FQDN (ie:host.example.com)hostname
- Change your sendmail host name if desired sendmailHostname
- Update DNS or DNSSEC accordingly
- Update SPF and DKIM, DNS TXT records accordingly
- Prepare a PKCS10 certificate request or go to an online certification enrollment
- Choose between self signed certificates or certificates from an external CA
- Use openssl command line opensslCli or CA web form
- Always enter your FQDN host name as CN (Common name) ie:host.example.com fillingDN
- Check that you request a certificate for client and server authentication purposes certsPurpose
- Retrieve your signed certificate certRetrieve
- Check it is in PEM format (base 64 encoded) and convert it if necessary
- Verify your certificate purpose certVerify
- check the content of your signed certificate certCheck
- Get your associated certificate key keyRetrieve
- Retrieve the Certification Authority certificate(s)CAcertsRetrieve
- Retrieve the Certification Authority CRL (certificate revocation list) CRLcertsRetrieve
- Update your certificates repository
- copy your private key in /etc/pki/tls/private.sendmail
- copy your public key in /etc/pki/tls/certs.sendmail
- copy the CA public key in /etc/pki/tls/certs.sendmail
- update certificate repository with CRLs in /etc/pki/tls/crls CRLcertsStore
- Setup a cron job to retrieve regularly updated CRLs CRLcertsCron
- Decide if you want to keep default Certification authorities bundled file certsBundle
- update /etc/mail/sendmail.mc
- define(`confCACERT_PATH',`/etc/pki/tls/certs.sendmail')
- define(`confCACERT',`/etc/pki/tls/certs.sendmail/ca-bundle.crt')
- define(`confSERVER_CERT',`/etc/pki/tls/certs.sendmail/smtp-host.bdl.crt')
- define(`confSERVER_KEY',`/etc/pki/tls/private.sendmail/smtp-host.key')
- define(`confCLIENT_CERT',`/etc/pki/tls/certs.sendmail/smtp-host.bdl.crt')
- define(`confCLIENT_KEY',`/etc/pki/tls/private.sendmail/smtp-host.key')
- define(`confCRL',`/etc/pki/tls/crls/openosiCA1-DC.crl')
- generate sendmail.cf (command: make -C /etc/mail)
- Start or restart sendmail (command: service sendmail restart)
- Check log files for errors (command: tail /var/log/maillog)
- Check for proper TLS activation activationTLS
- after a while check for proper TLS operations
edit message headers of a received mail
[root@example-host mail]# tail /var/log/maillog
May 15 04:04:20 smtp-host sendmail[8829]: STARTTLS=client, relay=dkcphmx52.softc
om.dk., version=TLSv1/SSLv3, verify=FAIL, cipher=AES256-SHA, bits=256/256
The value verify=FAIL indicates that sendmail was not able to verify the remote host certificate, but you still got an encrypted connection with these parameters: cipher=AES256-SHA, bits=256/256 . Only the value verify=NONE indicates that TLS is not used.
You may also use the following openssl command
Where "smtp-host.example.com" is your host name
[root@example-host mail]# openssl s_client -starttls smtp -showcerts -connect smtp-host.example.com:25
More about this command Here
 | Be Careful
You may have known remote hosts (MTA) that do not support correctly TLS protocol (i.e some old version of Microsoft Exchange or misconfigured MTAs). In that cases you could disable offering TLS with the following statement in your access file for bogus-host.example.com:
try_tls:bogus-host.example.com NO
|
Return to top of page topTLS
Adopt an external naming scheme, or define one for your OSI names
OSI stands for "Open Standards for Interconnection" from ISO / ITU
an OSI name is called a "Distinguished name" which is used in all OSI related technologies such as
- Certificates (X509)
- LDAP directories including Microsoft Active directory (X500)
- Military and aeronautical messaging systems (X400)
A "Distinguished name" (DN) is a collection of one or more of the following components
- CN Common name
- OU Organisation Unit
- O Organization
- C Country
- and many others like "gn givenname","sn surname","l location" ......
Example DN
DN: cn=My_full_name,ou=Related_Organisation_Unit,ou=other_related_unit,o=Company_name,c=country
or with the alternate DC scheme mostly used in directories.
DN:cn=My_full_name,ou=Related_Organisation_Unit,ou=other_related_unit,dc=example,c=com
Common meanings of OU are as follows:
- OU=Hosts
- OU=People # users
- OU=Services # Daemons
openOSI also uses in its naming scheme:
- OU=VirtualHosts
- OU=VirtualPeople # nicknames
- OU=PKI # Certification authorities
In principle you are free to use what you want as DN components value, unless you request a certification authority to certify these values. That is unless you intend a public use of these names to participate in an Internet of trust (similarly to the dns - Domain name system).
You MUST use a "Distinguished name" to generate a certificate request, see fillingDN
For additional information check the various OSI X500 and RFC
 | Useful Information
There could be links between DNS and OSI naming scheme, especially when domain components are used for distinguished names. Some people stores DNS DB in an LDAP directory (like Microsoft optionally). Most people don't in order to keep loosely coupling between DNS and Directories. There is an interesting use of LDAP directories for certificates when storing these certificates and their revocation list (CRL) in the directories. Therefore you MAY imagine a scheme that facilitate directory searching for your certificate retrieval. That is unless you use a third part directory like openOSI (directory.opensosi.org). openOSI practice is to store your certificate in virtual OU unit according the openOSI naming scheme without relying on the distinguished name of the certificate. See certCheck, CAcertsRetrieve, and CRLcertsRetrieve |
Return to top of page topTLS
Check your FQDN host name
[root@example-host mail]# hostname
example-host.example.com
Change your sendmail host name in /etc/mail/sendmail.mc
This will not change your current hostname, but this new name will be used for SMTP protocol exchanges. This is a virtual name of your host. Your certificate subject (CN), will be checked against this name, for TLS mode.
insert the following line for ie:smtp-host.example.com
define(`confDOMAIN_NAME', `smtp-host.example.com')dnl
- Generate sendmail.cf (command:
- Restart sendmail (command:service sendmail restart)
- Check your new sendmail configuration
[root@example-host ~]# sendmail -d0.1 -bv
Version 8.13.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET
6
NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS
TCPWRAPPERS USERDB USE_LDAP_INIT
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) \$w = example-host
(canonical domain name) \$j = smtp-host.example.com
(subdomain name) \$m = example.com
(node name) \$k = example-host.example.com
========================================================
Recipient names must be specified
 | Useful Information
It is best practice to have a separate host name for the sendmail protocol. This protects you against a misuse of the certificate and it's key if they are silently stolen. It will not be possible to impersonate your host with that certificate. There are also others advantages not related to certificates |
Return to top of page topTLS
Use openssl to generate a certificate request smtp-host.csr
[root@example-host mail]# openssl req -nodes -newkey rsa:1024 -keyout smtp-host.key -out smtp-host.csr
The outputs will be
- a private key, without password, with RSA coding and 1024 bit coding key named smtp-host.key
- a PKCS10 format certificate signing request named smtp-host.csr
 | Option
You may want to first generate the private key, then the signing request
[root@example-host mail]# openssl genrsa -out smtp-host.key 1024
[root@example-host mail]# openssl req -nodes -new -key smtp-host.key -out smtp-host.csr |
To verify the content of your signing certificate request (CSR)
[root@example-host mail]# openssl req -noout -text -verify -in smtp-host.csr
For more detailed information hit openssl request reference 
Return to top of page topTLS
Filling your certificate subject
This subject is bind to the cryptographic material of your certificate. Here is the real nature of a certificate. Therefore a certificate for sendmail should be bind to the virtual host running the service
see SendmailHostname.
Assign your host name to common name component. ie: cn=smtp-host.example.com
The others, optional, parts of the subject are
- Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
- Either a set of many Domain Components ie: "dc=example,dc=com" standing for example.com
- Optionally you may have organisation units ie: ou=Finance or ou=hosts or ou=services
- Optionally you may have additional cn as used by Microsoft naming scheme
Finally you obtain your subject value called a Distinguished Name abreviated as DN
- example 1: cn=smtp-host.example.com
- example 2: cn=smtp-host.example.com,o=My_Organisation,c=US
- example 3: cn=smtp-host.example.com,dc=example,dc=com
- example 4: cn=smtp-host.example.com,ou=services,dc=example,dc=com
This is the OSI naming scheme, also used in LDAP directories (like Microsoft AD) and X400 mail systems. If your certificate is stored in an LDAP directory, it could be stored in the same DIT (Directory Information Tree) as the one of it's Distinguished name, or it could be stored under another DIT.
openOSI stores the public signed certificates this way for class 1
- DIT is ou=VirtualHosts,dc=openosi,dc=org
- ObjectClass=top, ObjectClass=Device, ObjectClass=StrongAuthenticationUser
- cn=smtp-host.example.com - The cn value of certificate subject
- userCertificate="Binary form of your public certificate"
That is, if requesting an openOSI signed certificate, there is no need to fill something else than the common name as your host name, because openOSI will not certify additional information for its class 1 certification. Others parts like "o=My_Organisation, c=US" will be removed from the certificate unless you require a class 2 certificate (not available for now and subject to peer agreement).
 | Handy Hint
If you choose to generate yourself a certificate request (CSR) using openssl or any other tools including Microsoft windows based tools it could be mandatory to fill all attributes like country, organisation, organisation unit, location .... We recommend you enter as few information as possible, entering blanks where appropriate, because a certification authority is supposed to verify all the requested attributes. This is not necessary for sendmail operations and is costly (however the CA could silently drop some of your unverified attributes). Many HOW TO on internet suggest you create self signed certificates which avoid this problem. We don't recommend this unless you have the ability to manage a complete secure PKI (Public Key Infrastructure) to handle secure storage, directories, renewals and revocations. openOSI offers you a free open source PKI infrastructure for class 1 / 2 certification. |
Here is the openssl dialog
Country Name (2 letter code) [AU]: # enter . for blank
State or Province Name (full name) [Some-State]: # enter . for blank
Locality Name (eg, city) []: # enter . for blank
Organization Name (eg, company) [Internet Widgits Pty Ltd]: # enter . for blank
Organizational Unit Name (eg, section) []:. # enter . for blank
Common Name (eg, YOUR name) []:exampl-host.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Return to top of page topTLS
Verify your certificate purpose: client/server authentication
- If you use an on line submission, choose the appropriate submission form
- If you generate your request use the appropriate template
- If you use openssl check /etc/pki/tls/openssl.cnf for
- nsCertType= server,client
- keyUsage= digitalSignature,keyEncipherment
- default is to have nothing which allows all usage for your certificate, avoid this!
Key usage should be:
- Digital signature
- Key encipherment
- Data encipherment
Extended key usage should be (see RFC 3280):
- Server auth(include OID=1.3.6.1.5.5.7.3.1)
- client auth (include OID=1.3.6.1.5.5.7.3.2)
Return to top of page topTLS
Retrieve your signed certificate
You can retrieve your certificate from an on line certification authority or from an LDAP directory. In the later case you could only retrieve the public key, providing the private key was generated locally.
- For an on line retrieval go the appropriate URL of the certification authority
- For an LDAP retrieval, launch an LDAP query
- ie: for openOSI LDAP directory use the following URI
ldap://directory.openosi,org/ou=VirtualHost,dc=openosi,dc=org?userCertificate?one?cn=smtp-host.example.com
Return to top of page topTLS
Verify your certificate purpose
You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.
When editing the certificate details under "Enhanced key usage" it should show
Server Authentication(1.3.6.1.5.5.7.3.1)
Client Authentication(1.3.6.1.5.5.7.3.2)
Secure Email(1.3.6.1.5.5.7.3.4) # this is optional but usefull for address book storage (which is intended for persons)
When editing the certificate details under "key usage" it should show
Digital Signature, Key Encipherment, Data Encipherment(b0)
There is an openssl command to verify the purpose
In the example the certificate file name is: smtp-host.example.com.pem using PEM format
[root@example-host tls]# openssl x509 -in smtp-host.example.com.pem -noout -purpose
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
...
Verify certificate chain with Certification authority certificate file name: smtp-hostCA.crt
Should answer as shown
[root@example-host tls]# openssl verify -CAfile smtp-hostCA.crt -purpose sslserver smtp-host.example.com.pem
smtp-host.example.com.pem: OK
...
 | Useful Information
A certificate with no purpose (or Any Purpose : Yes) is a security risk. It could be misused if it is silently stolen from your host with its private key. It could allow anybody to impersonate you or any of your hosts daemons over the Internet. This risk is greater when you have not appropriate Public Key Infrastructure managing revocation lists of certificates. It's a good practice to limit the certificate to its main purpose AND to set it as critical. Be aware that silent defaults of most openssl HOW TO over Internet build any purpose certificates |
Return to top of page topTLS
check the content of your signed certificate for a correct cn
This cn should contain the FQDN of your host see SendmailHostname
The subject (DN) could be slightly different of the request because the Certification authority has removed the attributes it can't verify under its current policy (namely a level of assurance of class 1, 2 ...). This policy is indicated as a certificate practice statement or CSR
You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.
When editing the certificate details under "Subject", it should show
The order is not important
DC = com
DC = example
OU = Services
CN = smtp-host.example.com
When editing the certificate details with openssl command line, it should show:
In the example the certificate file name is: smtp-host.example.com.pem using PEM format
[root@example-host tls]# openssl x509 -noout -text -in smtp-host.example.com.pem
....
Subject: CN=smtp-host.example.com, OU=VirtualHosts, DC=example, DC=com
....
Note that DC and OU components MAY be empty. CN component MUST be present and reflect your fully qualified host name (or SENDMAIL virtual host name)
Return to top of page topTLS
Get your associated certificate key
Either locally or from the online enrollment
If it is from an on line certification authority, you probably retrieve a bundle of
- Your private key
- You signed certificate
- The Certification Authority certificate(s)
It comes in PKCS12 format (with .p12 extension for MS Windows)
You will have to export all the components to PEM format
Although the PKCS12 bundle is protected by a password, you should export your sendmail TLS private key with no password (as for a web server).
To export the private key from a PKCS12 bundle of name smtp-host.p12
[root@example-host tls]# openssl pkcs12 -nocerts -in smtp-host.p12 -out smtp-host.key
For more detailed information hit openssl pkcs12 reference 
Return to top of page topTLS
Retrieve the Certification Authority certificate(s)
If you used the openOSI Certification authority you will get the certificates here.
- Intermediate CA certificate of class 1: openosiCA1-DC
- Root CA certificate of class 3: openosiCA3-FR
You can also check our LDAP directory
ldap://directory.openosi,org/ou=PKI,dc=openosi,dc=org?cACertificate?one?cn=openosiCA1-DC
ldap://directory.openosi,org/ou=PKI,o=osi,c=fr?cACertificate?one?cn=openosiCA3-FR
If you have received a PKCS12 bundle of name smtp-host.p12
[root@example-host tls]# openssl pkcs12 -nokeys -cacerts -in smtp-host.p12 -out smtp-hostCA.crt
Create a hash symbolic link to the CA certificates in the same directory to speed up access.
Use the following command
[root@example-host tls]# ln -s smtp-hostCA.crt `openssl x509 -noout -hash < $1`.0
[root@example-host tls]# ln -s openosiCA1-DC.crt `openssl x509 -noout -hash < $1`.0
[root@example-host tls]# ln -s openosiCA3-FR.crt `openssl x509 -noout -hash < $1`.0
Return to top of page topTLS
Retrieve the Certification Authority CRL (certificate revocation list)
If you used the openOSI Certification authority you can retrieve the CRL for each CA certificate at the following URL
http://crl.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=opeosiCA1-DC,ou=pki,dc=openosi,dc=org
http://crl.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=opeosiCA3-FR,ou=pki,o=osi,c=fr
You can also check our LDAP directory
ldap://directory.openosi,org/ou=PKI,dc=openosi,dc=org?certificateRevocationList?one?cn=openosiCA1-DC
ldap://directory.openosi,org/ou=PKI,o=osi,c=fr?certificateRevocationList?one?cn=openosiCA3-FR
Otherwise you should check the value of "CRL Distribution points" in your certificate details, to get the appropriate URL.
Return to top of page topTLS
Update certificate repository with CRLs in /etc/pki/tls/crls
You also need to create a symbolic link to the hash of your crls as with certificates. But before, you should convert the CRL files you retrieve to PEM format. CRL files are often provided in DER format to fit browsers needs.
Counvert crl from der format to pem format
This example is with openosi crl files names, replace as appropriate to feet your needs
[root@example-host tls]# openssl crl -inform der -in openosiCA1-DC.crl -out openosiCA1-DC.crl.pem
[root@example-host tls]# openssl crl -inform der -in openosiCA3-FR.crl -out openosiCA3-FR.crl.pem
Create the symbolic link to the hash
This example is with openosi crl files names, replace as appropriate to feet your needs
[root@example-host tls]# ln -s $1 `openssl crl -noout -hash -in $openosiCA1-DC.crl.pem`.r0
[root@example-host tls]# ln -s $1 `openssl crl -noout -hash -in $openosiCA3-FR.crl.pem`.r0
Return to top of page topTLS
Setup a cron job to retrieve regularly updated CRLs
 | Be Careful
A Certificate revocation list is an important security feature. It allows checking for revoked certificates. When a certificate owner feels that a private key was compromised he revokes the certificate and get a new one. |
Cron job example for openOSI
No need to update the hash (the subject name doesn't change)
replace as appropriate to feet your needs
#!/bin/sh
# This goes through openOSI.org and upload updated CRL's
#
cd /etc/pki/tls/crls
# openosiCA1-DC.crl
/usr/bin/wget -O openosiCA1-DC.crl /
"http://cdp.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=openosiCA1-DC,ou=PKI,dc=openosi,dc=org" -q
/usr/bin/openssl crl -inform der -in openosiCA1-DC.crl -out openosiCA1-DC.crl.pem
# openosiCA3-FR.crl
/usr/bin/wget -O openosiCA3-FR.crl /
"http://cdp.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=openosiCA3-FR,ou=PKI,o=osi,c=fr" -q
/usr/bin/openssl crl -inform der -in openosiCA3-FR.crl -out openosiCA3-FR.crl.pem
Return to top of page topTLS
Decide if you want to keep default Certification authorities bundled file
Generally it is ca-bundle.crt as used in our example of sendmail.mc
define(`confCACERT',`/etc/pki/tls/certs.sendmail/ca-bundle.crt')
Sendmail recommends to keep this file small enough. On the other hand, these external CA certificates are used for TLS authentication. From that point of view, the more you have, more likely you could authenticate a peer.
 | Useful Information
A successfull authentication is not needed to established a TLS encrypted link, although it's needed for successfull EXTERNAL AUTHENTICATION. |
If you want a small ca-bundle.crt you could copy additional CA certificates in the CA certificate path that is indicated in our example sendmail configuration. You could also go this way to keep the default ca-bundle.crt file untouched and set additional accepted CA (Certification authorities).
define(`confCACERT_PATH',`/etc/pki/tls/certs.sendmail')
 | Handy Hint
Do not forget to set a hash symbolic link to the certificate. See CAcertsRetrieve |
Return to top of page topTLS
Check for proper TLS activation
[root@host-example ~]# sendmail -d0.1 -bv | grep -o STARTTLS
STARTTLS
The answer should be STARTTLS, otherwise you have a wrong configuration, or your version of sendmail doesn't support TLS.
EXTERNAL authentication is one of the sendmail authentication mechanisms, it is based on certificates. It allows to control relaying (i.e between Internet exposed MTA and internals MTA). This is a Single Sign On mechanism, allowing identities federation over the Internet. To configure EXTERNAL AUTH perform the following steps:
- Check for dependencies: (command: rpm -q cyrus-sasl answer: cyrus-sasl-2.1.21-10)
- Enable and start saslauthd enableSASL
- Enable authentication mechanism in /etc/mail/sendmail.mc sendmailAUTH
- Enable trust mechanism for relaying in /etc/sendmail.mc sendmailTRUST
- Choose what CA you want to trust (enabling TLS verify OK) trustCA
- Force incoming verification on a set of remote hosts clientTLS
- Force outgoing verification on a set of remote hosts serverTLS
- Control relaying with /etc/mail/access accessRELAY
- create a hash of your access file before re starting sendmail. accessHASH
- Check your log files and sendmail queue after a while
 | Warning
If you use RELAY_DOMAIN or RELAY_DOMAIN_FILE macros in sendmail.mc, your access statements for relaying are SILENTLY IGNORED, because the access database will not be checked. |
Return to top of page topEXTERNAL
Enable and start saslauthd
Many configuration options are available for SASL, but none is required for EXTERNAL AUTH to work. Keep defaults or your custom options.
Enable saslauthd
[root@example-host ~]# chkconfig saslauthd on
Start saslauthd
[root@example-host ~]# service saslauthd start
Check sasl support by sendmail
[root@example-host ~]# sendmail -d0.1 -bv root | grep SASLv2
NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS
You should have SASLv2 in the list, otherwise there is a misconfiguration or bad sendmail / cyrus-sasl version.
Check sasl supported mechanisms
[root@example-host ~]# saslauthd -v
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap
 | Useful Information
EXTERNAL AUTH doesn't use SASL but TLS level. Meanwhile it's recommended to setup minimal SASL defaults to keep consistent when using AUTH options in sendmail.mc . You are likely to use others secure AUTH mechanisms (i.e: GSSAPI - kerberosV) when EXTERNAL is not supported by a client. |
Return to top of page topEXTERNAL
Enable authentication mechanism in /etc/mail/sendmail.mc
*Define allowed authentication mechanism according RFC2554"
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI')dnl
You MAY have others mechanisms but MUST have EXTERNAL.
 | Useful Information
Others listed mechanisms are supported ONLY IF they are also supported by SASL, see enableSASL. |
Return to top of page topEXTERNAL
Enable trust mechanisms for relaying in /etc/sendmail.mc
TRUST_AUTH_MECH(`EXTERNAL GSSAPI')dnl
You MAY have others mechanisms but MUST have EXTERNAL.
Return to top of page topEXTERNAL
Choose which CA you want to trust (This is your authentication level)
You have roughly the following alternatives (you can mix)
- Trusting all default certification authorities
- Trusting a selected set of external certification authorities
- Trusting only the CA you use for your certificates
- Trusting a subset of the CAs you use for your certificates
When TLS is started (see startTLS), it is not always verified (value verify=OK). It means the certificate of the certification authority (CA), signing the certificate of the remote host, is not trusted by your host. To trust this host you should retrieve the CA certificate of the remote host and copy it to you trusted certificates path. This path is defined in your sendmail.mc file
define(`confCACERT_PATH',`/etc/pki/tls/certs.sendmail')
You get the remote CA certificate as you get your's CA certificate (see CAcertsRetrieve)
 | Useful Information
You may not need to retrieve the remote signing CA certificate for all hosts accepting to use TLS, because you immediately get verify=OK. It means that the corresponding remote signing CA certificate is already in your trust path. That is in the following "distro" default file, which is a bundle of many certification authorities:
define(`confCACERT',`/etc/pki/tls/certs.sendmail/ca-bundle.crt')
|
 | Warning
AUTH EXTERNAL will only be enabled if STARTTLS was successful and the client has been authenticated, i.e., verify is OK |
Return to top of page topEXTERNAL
Force incoming verification on a set of remote hosts
Update your access file as follows
Where trust-relay-in.example.com is a calling remote host (MTA)
TLS_Clt:trust-relay-in.example.com VERIFY
TLS_Clt:<other host> VERIFY
 | Useful Information
The TLS_Clt ruleset is used when sendmail acts as a server for incoming clients |
Here is a subset of the generated headers
May 13 04:03:40 smtp-host sendmail[30864]: STARTTLS=server, relay=trust-relay-in.example.com [10.1.0.1], version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Return to top of page topEXTERNAL
Force outgoing verification on a set of remote hosts
Update your access file as follows
Where trust-relay-out.example.com is a destination remote host (MTA)
TLS_Srv:trust-relay-out.example.com VERIFY
TLS_Srv:<other host> VERIFY
 | Useful Information
The TLS_Srv ruleset is used when sendmail acts as a client for destination servers |
Here is a subset of the generated headers
May 13 15:21:54 smtp-host sendmail[22165]: STARTTLS=client, relay=trust-relay-out.example.com., version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Return to top of page topEXTERNAL
Controlling relaying with /etc/mail/access
The EXTERNAL mechanism is based on certificates.
- The certificate MUST be verified (its certification authority is in your CA trust path, see trustCA.
- The certificate must be checked with access rules
- CERTISSUER rule (checking CA certificate)
- CERTSUBJECT rule (checking presented certificate)
Update the CERTISSUER rules in your /etc/mail/access file
The idea is to insert in your access file, statements allowing relaying from hosts (MTA) having a certificate signed by a given Certification authority (CA). You should use the Distinguished name (DN)of the accepted CA. This is the subject of CA certificate or the subject of the issuer of the remote host certificate (same value). The trick is that you should replace all non printing characters (i.e blank) with their hexadecimal value prefixed with a plus.
Here is an example with the openosiCA1-DC certification authority DN (subject)
DN:/CN=openosiCA1-DC/OU=pki/DC=openosi/DC=org/ # no need for translation
Here is an example with /CN=SECUR.NET class3 CA-DC/DC=pki/DC=openosi/DC=org/
/CN=SECUR.NET+20class+203+20CA-DC/DC=pki/DC=secur/DC=net/ # translated
Here is a subset of access file with openosiCA1-DC certification authority
...
CERTISSUER:/CN=openosiCA1-DC/OU=pki/DC=openosi/DC=org/ SUBJECT
CERTISSUER:/CN=openosiCA3-FR/OU=pki/o=osi/C=FR/ SUBJECT
...
The value SUBJECT forwards to a remote host certificate defined by the following CERTSUBJECT rules. You MAY have the value RELAY to accept relaying from all remote hosts having a certificate signed by CERTISSUER value.
 | Useful Information
The certificate of a certification authority MAY be signed by another certification authority. The signed CA is called an intermediate CA, the signing CA is called a root authority. A root authority has a self signed certificate. Therefore the trust goes to the entity self signing the certificate. In the example above
openosiCA1-DC is a class 1 openosi certification authority with domain component name space.
openosiCA3-FR is a class 3 openosi certification authority with a regular name space showing the legal entity name and its country of registration. A TLS verification process MAY check the whole certification chain (using openssl s_client with -verify depth) see startTLS. |
To check the policies attached to certificates authority you should check their OID value. For openosi see certification practice statements
Update the CERTSUBJECT rule in your /etc/mail/access file
You should use the Distinguished name (DN)of the accepted host (MTA). This is the subject of the certificate of the remote host certificate, see (i.e)
DN:cn=smtp-client.example.com,ou=services,dc=example,dc=com
Here is a subset of access file with remote host smtp-client.example.com
...
CERTSUBJECT:/CN=smtp-client.example.com/OU=services/DC=example/DC=com/ VERIFY
...
The right hand value instruct sendmail to verify the subject of the certificate and to check it against the sendmail host name, see .
Here is a subset of the generated headers
May 13 04:03:40 smtp-host sendmail[30864]: AUTH: available mech=DIGEST-MD5 GSS
API NTLM CRAM-MD5, allowed mech=EXTERNAL GSSAPI
...
May 13 04:03:40 smtp-host sendmail[30864]: STARTTLS=server, cert-subject=/CN=smtp-client.example.com/OU=services/DC=example/DC=com, cert-issuer=/CN=openosiCA1-DC/OU=pki/DC=openosi/DC=org/ , verifymsg=ok
The mail coming from smtp-client.example.com is accepted for relaying.
 | Be Careful
If the domain of the remote host (say: other-example.com) is not the same than the relying host you should add the following statement in your sendmail.mc file
VIRTUSER_DOMAIN(`other-example.com')
otherwise you will have the following error
May 13 14:28:28 smtp-host sendmail[26680]: l4DCSMb9026680: ruleset=check_rcpt, arg1=<audit.administrator@example.com>, relay=smtp-client.other-example.com [10.1.2.3], reject=550 5.7.1 <audit.administrator@example.com>... Relaying denied. Proper authentication required.
|
Return to top of page topEXTERNAL
create a hash of your access file before re starting sendmail.
[root@example-host ~]# makemap hash /etc/mail/access < /etc/mail/access
Restart sendmail
[root@example-host ~]# service sendmail restart