+<h2><a id="R14" name="R14">R14. Since upgrading fetchmail/OpenSSL, I can no longer connect!</a></h2>
+
+<p>If the upgrade you did encompassed an upgrade to OpenSSL 1.0.0 or newer, you
+may need to run <code>c_rehash</code> on your certificate directories,
+particularly if you are using local certs directories (f. i. through fetchmail's <code>--sslcertpath</code> option).</p>
+
+<p>Reason: OpenSSL 1.0.0, relative to earlier versions, uses a different hash
+for the symbolic links (symlinks) in its <code>certs/</code> directory, so you
+need to recreate the symlinks by running <kbd>c_rehash
+ /etc/ssl/certs</kbd> (adjust this to where your installation keeps its
+certificates), and you cannot easily share this certs directory with
+applications linked against older OpenSSL versions.</p>
+
+<p>Note: OpenSSL's <code>c_rehash</code> script is broken in several versions,
+which can cause malfunction if several OpenSSL tools versions are installed in
+parallel in separate directories. In such cases, you may need a workaround to
+get things going. Assuming your OpenSSL 1.0.0 is installed in
+<code>/opt/openssl1.0.0</code> and your certificates are in
+<code>/home/hans/certs</code>, you'd do this (the corresponding fetchmail
+option is <kbd>--sslcertpath /home/hans/certs</kbd> on the commandline and
+<kbd>sslcertpath /home/hans/cert</kbd> in the rcfile):</p>
+
+<pre>
+env PATH=/opt/openssl1.0.0/bin /opt/openssl1.0.0/bin/c_rehash /home/hans/certs
+</pre>
+
+<h2><a id="R15" name="R15">R15. Help, I'm getting Authorization failure!</a></h2>
+
+<p>First, try upgrading to fetchmail 6.3.18 or newer. Release 6.3.18 has
+received a considerable number of bug fixes for the authentication
+feature (AUTH, AUTHENTICATE, SASL). Most notably, fetchmail aborts SASL
+authentication attempts properly with an asterisk if it detects that it
+cannot make progress with a particular authentication scheme. This fixes
+issues where GSSAPI-enabled fetchmail cannot authenticate against
+Microsoft Exchange 2007 and 2010. <strong>Note</strong> that this is a
+bug in old fetchmail versions!</p>
+
+<p>Fetchmail by default attempts to authenticate using various schemes.
+Fetchmail tries these schemes in order of descending security, meaning
+the most secure schemes are tried first.</p>
+
+<p>However, sometimes the server offers a secure authentication scheme
+that is not properly configured, or an authentication scheme such as
+GSSAPI that requires credentials to be acquired externally. In some
+situations, fetchmail cannot know that the scheme will fail beforehand,
+without trying it. In most cases, fetchmail should proceed to the next
+authentication scheme automatically, but this sometimes does not
+work.</p>
+
+<p><strong>Solution:</strong> Configure the right authentication scheme
+explicitly, for instance, with <kbd>--auth cram-md5</kbd> or <kbd>--auth
+ password</kbd> on the command line or <code>auth "cram-md5"</code> or
+ <code>auth "password"</code> in the rcfile. Details can be found
+ in the manual page.<br />
+ <strong>Note</strong> that auth password should only be used
+ across secure links (see the sslcertck and ssl/sslproto options).
+ </p>
+