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.

Enabling TLS

You need to attach certificates and related stuff to the sendmail service. That is you have to perform the following steps:

1. 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
2. Retrieve the Certification Authority certificate(s)CAcertsRetrieve
3. Retrieve the Certification Authority CRL (certificate revocation list) CRLcertsRetrieve
4. 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
5. 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')
6. generate sendmail.cf (command: make -C /etc/mail)
7. Start or restart sendmail (command: service sendmail restart)
8. Check log files for errors (command: tail /var/log/maillog)
9. Check for proper TLS activation activationTLS
10. 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

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

---

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

1. Generate sendmail.cf (command:
2. Restart sendmail (command:service sendmail restart)
3. 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

The outputs will be

1. a private key, without password, with RSA coding and 1024 bit coding key named smtp-host.key
2. 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)

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

1. Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
2. Either a set of many Domain Components ie: "dc=example,dc=com" standing for example.com
3. Optionally you may have organisation units ie: ou=Finance or ou=hosts or ou=services
4. 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

1. example 1: cn=smtp-host.example.com
2. example 2: cn=smtp-host.example.com,o=My_Organisation,c=US
3. example 3: cn=smtp-host.example.com,dc=example,dc=com
4. 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

---

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

Verify certificate chain with Certification authority certificate file name: smtp-hostCA.crt
Should answer as shown

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

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

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

If you have received a PKCS12 bundle of name smtp-host.p12

Create a hash symbolic link to the CA certificates in the same directory to speed up access.
Use the following command

---

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

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

Create the symbolic link to the hash
This example is with openosi crl files names, replace as appropriate to feet your needs

---

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

---

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

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).

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

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:

1. Check for dependencies: (command: rpm -q cyrus-sasl answer: cyrus-sasl-2.1.21-10)
2. Enable and start saslauthd enableSASL
3. Enable authentication mechanism in /etc/mail/sendmail.mc sendmailAUTH
4. Enable trust mechanism for relaying in /etc/sendmail.mc sendmailTRUST
5. Choose what CA you want to trust (enabling TLS verify OK) trustCA
6. Force incoming verification on a set of remote hosts clientTLS
7. Force outgoing verification on a set of remote hosts serverTLS
8. Control relaying with /etc/mail/access accessRELAY
9. create a hash of your access file before re starting sendmail. accessHASH
10. 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

Start saslauthd

Check sasl support by sendmail

You should have SASLv2 in the list, otherwise there is a misconfiguration or bad sendmail / cyrus-sasl version.

Check sasl supported mechanisms

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"

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

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

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)

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

---

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)

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

---

Return to top of page topEXTERNAL

Controlling relaying with /etc/mail/access

The EXTERNAL mechanism is based on certificates.

1. The certificate MUST be verified (its certification authority is in your CA trust path, see trustCA.
2. 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

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

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

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.

Restart sendmail

Using TLS you can protect PLAIN text password when authenticating clients. If TLS is not activated your passwords are transmitted unencrypted.

To offer only encrypted authentication mechanisms update sendmail.mc

Options meaning
A: use AUTH from MAIL FROM after authentication for broken MTA
P: disallow use of PLAIN LOGIN unless STARTTLS ok
y: forbid anonymous login

Generate sendmail.cf and restart sendmail.

REMINDER

• Self-signed certificate usage is discouraged unless for non production environments
• Rudimentary openssl PKI usage is discouraged unless for non production environments
• Keep your certification revocation lists (CRL) up to date
• Downgrade to kerberos_V when TLS / EXTERNAL are not available (avoid PLAIN text passwords)
• LDAP directory is an identity repository, not an authentication nor an autorization service

and as usual
...

• Always check your trusted certification authorities (CA)
• Check the CA CPS (Certificate practice statement)to learn about the security policy
• Do not disable SELinux targeted
• Try to use -Multi categories security_ (MCS) to protect your files
• Use yum to update your packages
• Avoid to compile and install packages versions not supported / tested by your distro
• Have as many as possible linux box to handle separate services
• Use chrooted environments
• Keep Microsoft box out of Internet direct access
• Confine as much as possible RPC, XML-RPC and netbios
  ...