Enabling LDAPS (i.e LDAPS via SSL/TLS on port 636 or LDAPS via starttls on port 389) on active directory controllers requires a valid certificate to be added to each domain controller. Overall this process is reasonably documented, for example at How to enable LDAP over SSL with a third-party certification authority and Event ID 1220 — LDAP over SSL and LDAP over SSL (LDAPS) Certificate.

So the basic steps are generate a keypair, create a CSR, submit the CSR, obtain a cert and import a certificate into the AD DS personal store. Pretty usual process for certificates.

The missing bit of information is what to do when using OpenSSL to generate the key-pair and CSR. The certificate provided by the CA is likely to be in text .crt/.cer format (i.e. contains —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–). To import into the AD DS personal store we need to use a .pfx which includes the private key, the certificate and CA cert.

To create a .pfx we can do something like (all on one line…):

openssl pkcs12 -export -out servername.pfx -inkey servername- key.pem -in servername-crt.pem -certfile /path/to/rootCAcertificate.pem

We then transfer the .pfx file to the domain controller in question and follow the above documents’ directions.

Sendmail has done it again – proved just how powerful it is, as long as you know what you’re doing.

While investigating the configuration of the ciphers to used by Apache (SSLCipherSuite) and the associated SSLHonorCipherOrder option (to ensure the server’s cipher preference order is used), I realised that although I enable TLS on my Sendmail instances I don’t configure the cipher options. Given I’d spent some time coming up with my preferred cipher order for Apache (unfortunately RC4-SHA is fairly high on the list) I decided I may as well put it in place for other daemons which perform OpenSSL based encryption (Sendmail and IMAP for instance). Given the available Sendmail documentation is light on this subject I had to go digging.

The “standard” encryption related options (enabled with the STARTTLS define at compilation time) for Sendmail are pretty well documented and understood:

There are some other useful options available when the STARTTLS define is combined with the _FFR_TLS_1 define at compile time.


Note: You can determine the compile settings used for your version of Sendmail by running:

sendmail -d0.14 -bt < /dev/null


These four options do not appear to be documented properly anywhere – even the Sendmail source code is pretty light on their configuration syntax and use. The CipherList option is mentioned as an available option on a page titled “Tips and Tricks for Sendmail Hackers“, dated 2006-03-31. There are a few other web pages and blog posts which mention or show one how to use the CipherList option. No mention is made of the remaining three.

These four options are configured in the LOCAL_CONFIG section of your sendmail.mc file. The following is an example (which may or may not be suitable for you) of such a section:

O CipherList=HIGH:RC4-SHA:RC4-MD5


The options described:

CipherList : This option configures the available cipher list for encrypted connections. Your cipher list can be tuned by using the openssl ciphers -v command. Stronger ciphers are obviously better. Excluding weak ciphers may mean that very old clients will be unable to connect. Note that with SSLv3 and TLS1.x the client, by default, will select its preferred cipher from the server’s list.

ServerSSLOptions : This option configures the OpenSSL connection flags used for the SSL/TLS connections into Sendmail. By default Sendmail, and most other applications using the OpenSSL library, uses the SSL_OP_ALL composite flag for its connections. This option allows these flags to be altered. The first option to consider using is SSL_OP_CIPHER_SERVER_PREFERENCE. This option causes the server, rather than the client, to choose the cipher based on its preference order. The next option to consider is SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. This option disables a countermeasure against a SSLv3/TLSv1 protocol vulnerability. This flag disables the countermeasure and is set by default when SSL_OP_ALL is used. Thus, if one wishes to have the vulnerability countermeasure enabled, this flag needs to be disabled. Depending on the clients and servers of your Sendmail instance you may wish to consider the use of SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and SSL_OP_NO_TLSv1. Note that the current version of Sendmail does not have support for OpenSSL’s SSL_OP_NO_TLS_v1_1 nor for SSL_OP_NO_TLSv1_2. These two could be quite useful and I have submitted a patch to Sendmail for these to be included. The value of this parameter is used to manipulate the bits passed to OpenSSL. Note that Sendmail starts with a value of SSL_OP_ALL and this option modifies that value – it does not reset it from scratch. You manipulate the value using [+]SSL_OP_XXX to SET the bits and using -SSL_OP_XXX to CLEAR the bits. Thus a value of +SSL_OP_ALL would have no effect (since those bits are already set. A value of -SSL_OP_ALL would result in no bits being set. A useful value might be +SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE.

ClientSSLOptions : This option configures the OpenSSL connection flags used for the SSL/TLS connections initiated by Sendmail. The parameter’s value works the same as for ServerSSLOptions.

DHParameters512 : This option does not appear to actually be used. It is a valid configuration option which will be parsed. However, it appears as if this parameter is not used by the Sendmail source code at all!


As an aside, DHParameters is another odd configuration option. The documentation implies this is a file containing DH paramters. However, the source code in sendmail/tls.c has this to say:

** valid values for dhparam are (only the first char is checked)
** none no parameters: don't use DH
** 512 generate 512 bit parameters (fixed)
** 1024 generate 1024 bit parameters
** /file/name read parameters from /file/name
** default is: 1024 for server, 512 for client (OK? XXX)

So in fact, it is slightly more flexible than the documentation makes out. Note too, that should you wish to use a DH parameter of more than 1024 bits you will need to use an external file.

So with all that said, a useful set of parameters might be:
O CipherList=HIGH:RC4-SHA:RC4-MD5
O ClientSSLOptions=+SSL_OP_NO_SSLv2

So, based on this configuration, we are only using “high” strength ciphers and also two RC4 ciphers. You may want to remove the RC4-MD5 one if you are concerned about MD5’s strength. For maximum compatibility with old clients, you may want to keep it included. We don’t allow SSLv2 and we request that the server (i.e. our Sendmail instance) chooses the mutual cipher.

Hope this helps.

Another useful thing to note, is that when _FFR_TLS_1 is used you can use two certificates and key files for ServerCertFile and ServerKeyFile – with their names separated with simply a , (i.e. a comma and no spaces). This is useful if you have both an RSA and DSA certificate you wish to use. For example, the configured option within sendmail.cf would be:

O ServerCertFile=/etc/mail/tls/server-rsa.crt,/etc/mail/tls/server-dsa.crt
O ServerKeyFile=/etc/mail/tls/server-rsa.key,/etc/mail/tls/server-dsa.key

Due to constraints within OpenSSL’s SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate_file calls, both certificates should use the same certificate chain. More information can be found on OpenSSL’s website.