/tags/transport-layer-security/ Recent content in Transport Layer Security on Amit Agarwal Linux Blog Hugo -- gohugo.io en Mon, 15 Nov 2010 14:51:49 +0000 /2010/11/15/openldap-ssl-links/ Mon, 15 Nov 2010 14:51:49 +0000 /2010/11/15/openldap-ssl-links/ <!--[ad#ad-2]--> <p>Here are some of the links that may be of great help to you if you are having issues with setting up <a class="zem_slink" title="Transport Layer Security" rel="wikipedia" href="http://en.wikipedia.org/wiki/Transport_Layer_Security">SSL</a> and <a class="zem_slink" title="OpenLDAP" rel="homepage" href="http://www.openldap.org/">OpenLDAP</a>. I was having some issues with this setup and these links helped me fix the same.</p> <p><a href="http://www.faqs.org/docs/Linux-HOWTO/SSL-RedHat-HOWTO.html">http://www.faqs.org/docs/Linux-HOWTO/SSL-RedHat-HOWTO.html</a> <a href="http://www.tc.umn.edu/~brams006/selfsign_redhat.html"></a></p> <p><a href="http://www.tc.umn.edu/~brams006/selfsign_redhat.html">http://www.tc.umn.edu/~brams006/selfsign_redhat.html</a></p> <p><a href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/Using_Red_Hat_Console/Starting_the_Server_with_SSL_Enabled-Enabling_SSL_in_the_DS_Admin_Server_and_Console.html">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/Using_Red_Hat_Console/Starting_the_Server_with_SSL_Enabled-Enabling_SSL_in_the_DS_Admin_Server_and_Console.html</a></p> <p><a href="http://directory.fedoraproject.org/wiki/Howto:SSL">http://directory.fedoraproject.org/wiki/Howto:SSL</a> <a href="http://www.linuxtopia.org/online_books//network_administration_guides/ldap_administration/appendix-common-errors_Common_causes_of_LDAP_errors.html">http://www.linuxtopia.org/online_books//network_administration_guides/ldap_administration/appendix-common-errors_Common_causes_of_LDAP_errors.html</a></p> <!-- LDAP-SSL ======================================== Purpose/Scope of this Guide The purpose of this guide is to assist <a class="zem_slink" title="Red Hat Linux" rel="homepage" href="http://www.redhat.com" mce_href="http://www.redhat.com">RedHat Linux</a> users with the installation of server (SSL) certificates using the <a class="zem_slink" title="Apache HTTP Server" rel="homepage" href="http://httpd.apache.org/" mce_href="http://httpd.apache.org/">Apache web server</a>. The goal is to provide a clear procedure that will save time and, in many cases, money! First, I will cover what you need to know about the SSL protocol and digital certificates. In my experience, building an Apache web server with ModSSL and <a class="zem_slink" title="OpenSSL" rel="homepage" href="http://www.openssl.org/" mce_href="http://www.openssl.org/">OpenSSL</a> is the most beneficial software combination. OpenSSL is a general-purpose cryptography library that supports the SSL v2/v3 and TLS v1 protocols. ModSSL is an Apache API module designed to act as an interface between Apache and OpenSSL. The biggest advantage is that all three packages are free. Then, beginning with Section 4, I will go through the step-by-step procedures for generating keys and installing certificates on a RedHat-Apache server compiled with ModSSL and OpenSSL. The procedures in Section 4 will also work with commercial SSL-server packages such as Stronghold and Raven that are closely related to Apache. Disclaimer: I am a technical support engineer for <a class="zem_slink" title="Equifax" rel="homepage" href="http://www.equifax.com" mce_href="http://www.equifax.com">Equifax</a> Secure Inc., a Certificate Authority. Therefore, I use Equifax Secure certificates and examples geared towards installing Equifax Secure certificates. However, the instructions will also work with certificates issued by other <a class="zem_slink" title="Certificate authority" rel="wikipedia" href="http://en.wikipedia.org/wiki/Certificate_authority" mce_href="http://en.wikipedia.org/wiki/Certificate_authority">Certificate Authorities</a>. Since this document was written at my own initiative, Equifax Secure Inc. is neither liable nor accountable for any consequences resulting from the use of these procedures. My comments to the reader is in this style (emphasized). Example lines are in plain roman style. Note that extra comments and advice is found in comments within the SGML source. 1.1 About <a class="zem_slink" title="Transport Layer Security" rel="wikipedia" href="http://en.wikipedia.org/wiki/Transport_Layer_Security" mce_href="http://en.wikipedia.org/wiki/Transport_Layer_Security">Secure Sockets Layer</a> (SSL) SSL is a presentation layer service, located between the TCP and the application layer. It is platform and application independent. SSL is responsible for the management of a secure communications channel between the client and server. SSL provides a strong mechanism for encrypting data transferred between a client and a server. 1.2 FeedBack Comments on this guide may be directed to the author (richard.sigle@equifax.com). 1.3 Copyrights and Trademarks Copyright (c) 2001 by Richard L. Sigle Please freely copy and distribute this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you: * Send your derivative work (in the most suitable format such as sgml) to the LDP (<a class="zem_slink" title="Linux Documentation Project" rel="wikipedia" href="http://en.wikipedia.org/wiki/Linux_Documentation_Project" mce_href="http://en.wikipedia.org/wiki/Linux_Documentation_Project">Linux Documentation Project</a>) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available. * License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used. * Give due credit to previous authors and major contributors. If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer. 1.4 Acknowledgements and Thanks I would like to thank Tony Villasenor for tirelessly reading my drafts and offering his input and advice. Without Tony, this document would never have been finished. ________________________________________________________________________ 2. Introduction to Secure Sockets Layer/Private Key Infrastructure <a class="zem_slink" title="Public key infrastructure" rel="wikipedia" href="http://en.wikipedia.org/wiki/Public_key_infrastructure" mce_href="http://en.wikipedia.org/wiki/Public_key_infrastructure">PKI</a> is an asymmetric key system which consists of a public key (which is sent to clients) and a private key (stays local on the server). PKI differs from a symmetric key system in which both the client and server use the same key for encryption/decryption. 2.1 Responsibilities of SSL/PKI SSL sets out to fulfill requirements that make it acceptable for use in the transmission of even the most sensitive of transactions, such as credit card information, medical records, legal documents, and e-commerce applications. Each application can choose to utilize some or all of the following criteria depending on the sensitivity and value of the transactions it will be processing. Privacy Let's say that a message is to be coded for transmission from A to B. A uses B's public key to encrypt the message. In this way B will be the only person who can decode and read this message using his private key. We cannot however be sure that A is the person who he claims to be. Authenticity In order to be sure that A is the person who he claims to be, we want guaranteed authenticity. This requires a slightly more complex coding process. In this case, A's message to B is first encrypted with A's private key and then with B's public key. B now has to decrypt it first with his private key and then with A's public key. Now B can be sure that A is who he claims to be as nobody else could create a message encrypted with his private key. SSL achieves this with the use of certificates (PKI). A certificate is issued by a neutral third party - such as a certificate authority (CA) - and includes a digital signature and/or a time stamp in addition to the public key of the certified party. A self-signed digital certificate can be created by anyone with the correct SSL tools, but self-signed certificates lack the weight of validation performed by a mutually respected neutral third party. integrity In SSL, integrity is guaranteed by using a MAC (<a class="zem_slink" title="Message authentication code" rel="wikipedia" href="http://en.wikipedia.org/wiki/Message_authentication_code" mce_href="http://en.wikipedia.org/wiki/Message_authentication_code">Message Authentication Code</a>) with the necessary hash table functions. Upon generation of a message, the MAC is obtained by applying a hash function and the result is then added to the message. After the message has been received, validity is then checked by comparing the message's embedded MAC with a new MAC computed from the received message. This would immediately reveal messages that have been altered by a third party. <a class="zem_slink" title="Non-repudiation" rel="wikipedia" href="http://en.wikipedia.org/wiki/Non-repudiation" mce_href="http://en.wikipedia.org/wiki/Non-repudiation">Non-Repudiation</a> Non-repudiation protects both parties from each other during online transactions. It prevents one or the other from saying that they did not send a particular piece of information. Non-repudiation does not allow either party to alter the transaction after it has been made. Digital non-repudiation is the equivalent of signing a contract, in the traditional sense. 2.2 How SSL Works The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection. This exchange of messages is designed to facilitate the following actions: * Authenticate the server to the client. The server certificate is signed by a Certificate Authority to insure that it is not corrupted and establishes a chain of trust. * Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support. * Optionally authenticate the client to the server. * Use public-key encryption techniques to generate shared secrets. * Establish an encrypted SSL connection. SSL Handshake Protocol The Handshake Protocol is used to co-ordinate the state of the client and the server. During the handshake, the following events take place: * Certificates are exchanged between the client and server (asymmetric keys). The server sends its public key to the client. If the server is set to verify client authentication via a certificate, the client sends its public key to the server. The validity dates on the certificates are verified and they are checked for the digital signature of a trusted certificate authority. If the validity date and/or digital signature are not correct, the browser will issue a warning to the user. The user is then given the option to trust the certificate holder. * The client then generates a random key (symmetric key). These will be used for encryption and for calculating MACs. They are encrypted using the server's public key and sent to the server. Only the server has the ability to decrypt the new random key. The new symmetric key is used for encrypting the data that is sent between client and server. Note: The use of a symmetric key after server-browser authentication greatly enhances subsequent throughput performance. * A message encryption algorithm and a hash function for integrity are negotiated. This negotiation process could be carried out such that the client presents a list of supported algorithms to the server, which, in turn, selects the strongest cipher available to both of them. Identifiers for the chosen encryption algorithm and hash function are stored in the cipher spec field of the current state for use by the record protocol. * All of the following fields are set during handshaking: Protocol Version, Session ID, Cipher Suite, Compression Method and two random values ClientHello.random and ServerHello.random. Note: An IP address is required for each SSL connection. Name based virtual hosts are resolved during the application layer. Remember Secure Sockets Layer resides below the application layer. Session Key(Symmetric Code) * 40-bit, originally used only for export purposes * 56-bit, used by DES * 64-bit key - used by CAST, 256 times stronger than 56-bit * 80-bit key - used by CAST, 16 million times stronger than 56-bit (infeasible to break with current technology) * 128-bit key - used by CAST or RC2, exhaustive key search impossible now and for the foreseeable future Public/Private Key Pair(Asymmetric Code) * 512-bit * 768-bit * 1024-bit * 2048-bit 2.3 How PKI Works The client and the server each have a public key and a private key (the client's browser randomly creates a key pair for the SSL session, unless, a client certificate is held by the client and requested by the server). The sender uses their private key to encrypt a message. This act authenticates the source of the message. The resulting cipher is encrypted once more with the receiving party's public key. This action provides confidentiality because only the receiving party is able to do the initial decryption of the message using their private key. The receiver uses the sender's public key to further decrypt the encrypted message. Because only the sender has access to their private key, the receiver is assured that the encrypted message originated from the sender. A message digest is used to verify that neither party or a third party has tampered with or changed the message in any way. A message digest is obtained by applying a hash function (part of the private key known as the fingerprint) to the message. The digest (which is now known as the signature) is attached or appended to the message. The signature's length is constant (no matter how large the file is) and depends on what type of message digest the private key contains (md5 - 128 bit, sha1 - 160 bit, etc). Changing even one bit in the message will change the length of the signature and thus prove that the message has been tampered with. 2.4 Certificates(x509 Standard) Digital certificates make it possible to trust an entity on the Internet. A digital certificate contains the user's credentials, which have been verified by a neutral third-party certificate authority. A mathematical algorithm and a value (key) are used to encrypt data into an unreadable form. A second key is used to decrypt the data, using a complementary algorithm and a related value. The two keys must contain a related value and are known as a key pair. Note: ITU-T Recommendation X.509 [CCI88c] specifies the authentication service for X.500 directories, as well as the X.509 certificate syntax. The certificate is signed by the issuer to authenticate the binding between the subject (user's) name and the user's public key. SSLv3 was adopted in 1994. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions. An X.509 certificate consists of the following fields: * Version * serial number * signature algorithm ID * issuer name * validity period * subject (user) name * subject public key information * issuer unique identifier (version 2 and 3 only) * subject unique identifier (version 2 and 3 only) * extensions (version 3 only) * signature on the above fields 2.5 Digital Certificate Private Key The private key is not embedded within a digital certificate. The private key does not include any server information. It contains encryption information and a fingerprint. It is generated locally on your system and should remain in a secure environment. If the private key is compromised, a perpetrator essentially has the code to your security system. The transmissions between client and server can be intercepted and decrypted. This type of vulnerability is why it is recommended to create a private key that is encrypted using triple DES technology. The file is then encrypted and password protected making it all but impossible to use without the correct pass phrase. The security of a transaction is dependent on its private key. Should this key fall into the wrong hands then anyone can easily duplicate it and use it to compromise security. A compromised key could lead to messages meant for the server to be intercepted and manipulated by unscrupulous hackers. A fully secure system must be able to detect impostors and prevent the duplication of keys. 2.6 Digital Certificate Public Key The public key is embedded in a digital certificate, which is sent by the server to a client when a secure connection is requested. This process identifies the server using the certificate. The public key validates the integrity, authenticity, and is also used to encrypt data to create a private data transmission. 2.7 Certificate Signing Request(CSR) A CSR contains the information required by a certificate authority to create the certificate. The CSR contains an encrypted version of the private key's complimentary algorithm, common value, and information that identifies the server. This information includes, but is not limited to, country, state, organization, common name (domain name), and contact information. ________________________________________________________________________ 3. Working with Certificates The following section covers the steps involved in creating the private key file, certificate signing request, and a self-signed certificate. If you plan to obtain a certificate signed by a certificate authority, you will need to create a certificate signing request (CSR). Otherwise, you can create a self-signed certificate. 3.1 Create a Private Key To create a private key, you must have the OpenSSL toolkit installed and configured with Apache. The following examples use the OpenSSL command line tool which is located in the /usr/local/ssl/bin directory by default. The examples assume that the directory containing the OpenSSL command line tool has been added to the $PATH. To create a private key using the triple des encryption standard (recommended), use the following command: openssl genrsa -des3 -out filename.key 1024 You will be prompted to enter and re-enter a pass phrase. If you choose to use triple des encryption, you will be prompted for the password each time you start the SSL server from a cold start. (When using the restart command, you will not be prompted for the password). Some of you may find this password prompt to be a nuisance, especially if you need to boot the system during off-hours. Or, you may believe that your system is already sufficiently secure. So, if you choose not to have a password prompt (hence no triple des encryption), use the command below. If you would rather create just a 512-bit key, then omit the 1024 at the end of the command and OpenSSL will default to 512 bits. Using the smaller key is slightly faster, but it is also less secure. To create a private key without triple des encryption, use the following command: openssl genrsa -out filename.key 1024 To add a password to an existing private key, use the following command: openssl -in filename.key -des3 -out newfilename.key To remove a password from an existing private key, use the following command: openssl -in filename.key -out newfilename.key Note: Your private key will be created in the current directory unless otherwise specified. There are 3 easy ways to deal with this. If OpenSSL is in your path, you can run it from the directory that you have designated to store your key files in (default is /etc/httpd/conf/ssl.key if you installed Apache using the RPM or /usr/local/apache/conf/ssl.key if you installed Apache using the source files). Another solution is to copy the files from the directory where they were created to the correct directory. And, last but not least, you can specify the path when running the command (eg. openssl genrsa -out /etc/httpd/conf/ssl.key/filename.key 1024). Doesn't matter how you do it as long as it gets done before you proceed. For more information on the OpenSSL toolkit check out: OpenSSL Website. 3.2 Create a Certificate Signing Request To obtain a certificate signed by a certificate authority, you will need to create a Certificate Signing Request (CSR). The purpose is to send the certificate authority enough information to create the certificate without sending the entire private key or compromising any sensitive information. The CSR also contains the information that will be included in the certificate, such as, domain name, locality information, etc. * Locate the private key that you would like to creat a CSR from. Enter the following command: openssl req -new -key filename.key -out filename.csr * You will be prompted for Locality information, common name (domain name), organizational information, etc. Check with the CA that you are applying to for information on required fields and invalid entries. * Send the CSR to the CA per their instructions. * Wait for your new certificate and/or create a self-signed certificate. A self-signed certificate can be used until you receive your certificate from the certificate authority. Note: Use the following command to create a private key and request at the same time. openssl genrsa -des3 -out filename.key 1024 3.3 Creating a Self-Signed Certificate It is not necessary to create a self-signed certificate if you are obtaining a CA-signed certificate. However, creating a self-signed certificate is very simple. All you need is a private key and the name of the server (fully qualified domain name) that you want to secure. You will be prompted for information such as locality information, common name (domain name), organizational information, etc. OpenSSL gives you a great deal of freedom here. The only required field for the certificate to function correctly is the common name (domain name) field. If this is not present or incorrect, you will receive a Certificate Name Check warning from your browser. To create a self-signed certificate: openssl req -new -key filename.key -x509 -out filename.crt 3.4 Installing your Web Server Certificate If you followed these instructions so far you shouldn't have any problems at this point. If you sent your CSR to a certificate authority and you have not gotten your certificate back yet, you can take a break now! If you are using a self-signed certificate, or you have received your certificate, you may continue. * Ensure that the private key file is in the directory that you have chosen to use. The following examples will be based on the RedHat RPM installation default of /etc/httpd/conf/ssl.key. * Ensure that the CA-signed or self-signed certificate is in its designated location. Again, I will be using the RPM default of /etc/httpd/conf/ssl.crt. If it is not there already, put it there. * If there is an intermediate (root) certificate to be installed, copy it to the /etc/httpd/conf/ssl.crt directory, also. * Now, you will be required to edit the httpd.conf file. Make a back-up of this file before you proceed to the next step, Configuring your Apache Server. ________________________________________________________________________ 4. Configuring your Apache Server The Apache server must be configured with supplementary API modules in order to support SSL. There are many SSL software packages available. My examples are based on Apache configured with ModSSL and OpenSSL. There are countless mailing lists and newsgroups available to support these products. You may find these instructions helpful for some commercial SSL software packages that are based on the Apache web server. A few things to keep in mind: You can have multiple virtual hosts on the same server. You can have numerous name-based virtual hosts on the same IP address. You can also have numerous name-based virtual hosts and one (1) secure virtual host on the same IP. But - you cannot have multiple secure virtual hosts on the same IP. The question that so many ask: Why? The answer is: SSL works below the application layer. Name based hosts are not defined until the application layer. Specifically, you cannot have multiple secure virtual hosts on the same SOCKET (IP address + port). By default, a secure host will use port 443. You can change configure your virtual host to use a different port number with the same IP, thus creating another socket. There are many disadvantages to this approach. The most obvious disadvantage is that if you are not using the default port, your URL must also contain the port number to access the secure site. Example: * Site using default port - <a href="http://www.something.com" mce_href="http://www.something.com">www.something.com</a> - would be accessed as <a href="https://www.something.com" mce_href="https://www.something.com">https://www.something.com</a> * A site using port 8888 would be accessed as <a href="https://www.something.com:8888" mce_href="https://www.something.com:8888">https://www.something.com:8888</a> Another disadvantage is that if you introduce more ports, you will be providing more opportunities for port sniffing hackers. Last, if you select a port that is used by something else, you will create conflict problem. 4.1 Define a Secure Virtual Host Setting up virtual hosts is fairly straightforward. I will go through the basics of setting up a secure virtual host. In these examples, I use the .crt and .key file extensions. That is my personal way of avoiding confusion with the various files. With Apache, you can use any extension you choose - or no extension at all. All of your secure virtual hosts should be contained within and , usually located towards the end of the httpd.conf file. An example of a secure virtual host: DocumentRoot /etc/httpd/htdocs ServerName <a href="http://www.somewhere.com" mce_href="http://www.somewhere.com">www.somewhere.com</a> ServerAdmin <a href="mailto:someone@somewhere.com" mce_href="mailto:someone@somewhere.com">someone@somewhere.com</a> ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown CustomLog /etc/httpd/logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b" The directives that are the most important for SSL are the SSLEngine on, SSLCertificateFile, SSLCertificateKeyFile, and in many cases SSLCACertificateFile directives. SSL Engine "SSLEngine on" - this is ModSSL's command to start SSL. SSLCertificateFile SSLCertificateFile Tells Apache where to find the certificate file and what it is named. The example above shows "server.crt" as the certificate file name. This is the default that is added when you configure ModSSL with Apache. I personally don't recommend using the default names. Save yourself some frustration and name your certificates as servername.crt (domainname.crt). You may also decide to use an alternative directory than the default /etc/httpd/conf/ssl.crt or /usr/local/apache/conf/ssl.crt. Just remember to make the necessary changes to the path. SSLCertificateKeyFile SSLCertificateKeyFile tells Apache the name of the private key and where to find it. The directory defined here should have read/write permissions for root only. No one else should have access to this directory. SSLCACertificateFile The SSLCACertificateFile directive tells Apache where to find the Intermediate (root) certificate. This directive may or may not be necessary depending on the CA that you are using. This certificate is essentially a ring of trust. Intermediate Certificate - A Certificate Authority obtains a certificate in much the same way as you. This is known as an intermediate certificate. It basically says that the holder of the intermediate certificate is whom they say they are and is authorized to issue certificates to customers. Web browsers have a list of "trusted" certificate authorities that is updated with each release. If a Certificate authority is fairly new, its intermediate certificate may not be in the browser's list of trusted CA's. Combine this with the fact that most people don't update their browsers very often; it could take years before a CA is recognized as trusted automatically. The solution is to install the intermediate certificate on the server using the SSLCACertificateFile directive. Usually, a "trusted" CA issues the intermediate certificate. If it is not, then you may need to use the SSLCertificateChainFile directive, although this is unlikely. 4.2 Certificate Examples Server Certificate File <div class="zemanta-pixie" style="margin-top: 10px; height: 15px;"><a class="zemanta-pixie-a" title="Enhanced by Zemanta" href="http://www.zemanta.com/" mce_href="http://www.zemanta.com/"><img class="zemanta-pixie-img" style="border: medium none; float: right;" mce_style="border: medium none; float: right;" src="https://i1.wp.com/img.zemanta.com/zemified_e.png?w=688" mce_src="https://i1.wp.com/img.zemanta.com/zemified_e.png?w=688" alt="Enhanced by Zemanta" data-recalc-dims="1" /></a><span class="zem-script more-related pretty-attribution"><mce:script mce_src="http://static.zemanta.com/readside/loader.js" type="text/javascript"></mce:script></span></div> --> <h6 class="zemanta-related-title" style="font-size: 1em;"> Related articles </h6> <ul class="zemanta-article-ul"> <li class="zemanta-article-ul-li"> <a href="http://www.shermann.name/2010/08/ubuntu-1004-lts-and-openldap.html">Stephan Hermann: Ubuntu 10.04 LTS and OpenLDAP</a> (shermann.name) </li> <li class="zemanta-article-ul-li"> <a href="http://intridea.com/posts/exploring-ldap-sasl-authentication-with-ruby">Exploring LDAP SASL Authentication With Ruby</a> (intridea.com) </li> <li class="zemanta-article-ul-li"> <a href="http://www.shermann.name/2010/08/solved-openldap-passwd-and-crypt.html">Stephan Hermann: [SOLVED] OpenLDAP, passwd and CRYPT passwords</a> (shermann.name) </li> <li class="zemanta-article-ul-li"> <a href="http://www.edugeek.net/forums/virtual-learning-platforms/61792-moodle-slow-ldap-login.html">Moodle &#8211; Slow LDAP Login</a> (edugeek.net) </li> </ul> <div class="zemanta-pixie" style="margin-top: 10px; height: 15px;"> <a class="zemanta-pixie-a" title="Enhanced by Zemanta" href="http://www.zemanta.com/"><img class="zemanta-pixie-img" style="border: medium none; float: right;" src="https://i1.wp.com/img.zemanta.com/zemified_e.png?w=688" alt="Enhanced by Zemanta" data-recalc-dims="1" /></a><span class="zem-script more-related pretty-attribution"></span> </div> /2010/03/09/swaks-swiff-army-nife-for-smtp/ Tue, 09 Mar 2010 03:52:02 +0000 /2010/03/09/swaks-swiff-army-nife-for-smtp/ <!--[ad#ad-2]--> <p>If you are having issues with the &lt;a class=&quot;zem_slink freebase/en/simple_mail_transfer_protocol&quot; title=&quot;Simple Mail Transfer Protocol&quot; rel=&quot;wikipedia&quot; href=&quot;http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol&quot;&gt;SMTP</a> Server, then sometimes you just wish you had a swiss army knife to test the same and then you would not have to spend your precious time on some silly mistake that you may have made. Your wish is now fulfilled.</p> <blockquote> <p>&lt;a class=&quot;zem_slink freebase/en/military_of_switzerland&quot; title=&quot;Military of Switzerland&quot; rel=&quot;wikipedia&quot; href=&quot;http://en.wikipedia.org/wiki/Military_of_Switzerland&quot;&gt;Swiss Army</a> Knife SMTP: A &lt;a class=&quot;zem_slink freebase/en/command_line_interface&quot; title=&quot;Command-line interface&quot; rel=&quot;wikipedia&quot; href=&quot;http://en.wikipedia.org/wiki/Command-line_interface&quot;&gt;command line</a> SMTP tester.  Swaks can test various aspects of your SMTP &lt;a class=&quot;zem_slink freebase/en/server&quot; title=&quot;Server (computing)&quot; rel=&quot;wikipedia&quot; href=&quot;http://en.wikipedia.org/wiki/Server_%28computing%29&quot;&gt;server</a>, including &lt;a class=&quot;zem_slink freebase/en/transport_layer_security&quot; title=&quot;Transport Layer Security&quot; rel=&quot;wikipedia&quot; href=&quot;http://en.wikipedia.org/wiki/Transport_Layer_Security&quot;&gt;TLS</a> and AUTH.</p>