Fix broken doc links and http→https where possible

I got a cookie-cutter email from folks noting the modssl.org doc links
were broken and asking us to use their site instead, which was both
helpful and a rather heavy page with advertising on it, so not something
I want our docs to link to.

Fixed the modssl link to point to the correct current Apache docs, since
mod_ssl has not been a separate project for … a very long time.

Audited every `http:` link in the Spec, replacing with https if
available, updating URLs as needed, or trimming deadwood as appropriate.
This did edit one license text, but in a way which I believe is
reasonable and in the license holder's best interests.

* Use comments with a datestamp for any remaining http: URLs, showing
  when they were last audited
* Suggest migrating away from Berkeley DB.
* Drop mention of a patched `pam_unix` module which is no longer available.
* In revamping the CDB tools links, add my own tools.
* Redo the intro text for the mod_ssl stuff (first person voice of PH).
* Rescorla's book's online examples appear to be gone; drop mention of
  them and point to Ristić's more recent book too.
* Point to wikipedia list of DNSxL services as an overview, in part
  because I dropped the reference to the defunct rfc-ignorant.org and
  there was no good candidate as an exemplar for domain-based lists.
* Note that mksd is a candidate for removal from Exim since mks_vir
  is dead.
* Drop LogReport/lire reference (dead/gone and can't find it).
* Redo proxy protocol spec-linking text.
* Replace FAQ A1701 with text saying "don't do that" (self-signed certs)
  and just telling people to use a CA instead, pointing strongly to
  Let's Encrypt.  We did nobody any favors with that old text still
  being present today (it was entirely appropriate when written).

1 files changed, 7 insertions, 75 deletions

diff --git a/doc/doc-src/FAQ.src b/doc/doc-src/FAQ.src
index 1ff867b62..47b810e5d 100644
--- a/doc/doc-src/FAQ.src
+++ b/doc/doc-src/FAQ.src
@@ -5740,82 +5740,14 @@ Q1701: I am trying to set up an Exim server that uses a self-signed certificate
        to enable my clients to use TLS. However, clients other than Exim
        refuse to accept this certificate. What's wrong?
 
-A1701: It seems that some clients require that the certificate presented by
-       the server be a user (also called ``leaf'' or ``site'') certificate, and not
-       a self-signed certificate. In this situation, the self-signed
-       certificate must be installed on the client as a trusted root
-       \*certification authority*\ (CA), and the certificate used by the server
-       must be a user certificate signed with that self-signed certificate.
-
-       For information on creating self-signed CA certificates and using them
-       to sign user certificates, see the \*General implementation overview*\
-       chapter of the Open-source PKI book, available online at
-       \?http://ospkibook.sourceforge.net/?\. Here is a quick overview. First,
-       read this message:
-
-       \?http://www.FreeBSD.org/cgi/mid.cgi?id=3C3F3A93.C1ECF9B0%40mindspring.com?\
-
-       Then, follow the instructions found on these two (consecutive) pages:
-
-       \?http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/initialisation.htm?\
-       \?http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/keygensign.htm?\
-
-       Two points on the PKI Book literature:
-
-       (1) It's assumed that it's okay to use a passphrase-protected key to
-           encrypt the user/site/leaf certificate. If this isn't acceptable,
-           you seem to be able to strip out the passphrase as follows:
-
-==>          openssl rsa -in user.key -our user.key.new
-             mv user.key.new
-
-           This should be done immediately after \(user.key)\ is created.
-
-       (2) The \*sign.sh*\ script is available in the \*mod_ssl*\ distribution,
-           available at \?http://www.modssl.org/source/?\.
-
-       Having followed the instructions, you end up with the following files:
-
-       (a) \(ca.crt)\
-
-       This file should be installed into the client software as a trusted
-       root certification authority. In Windows XP, this can be done as follows:
-
-       \#\#Call the file \(ca_cert.cer)\
-       [[br]]
-       \#\#Double-click on the file
-       [[br]]
-       \#\#"Install Certificate";
-       [[br]]
-       \#\#"Next"
-       [[br]]
-       \#\#"Place all certificates in the following store"
-       [[br]]
-       \#\#"Browse..."
-       [[br]]
-       \#\#"Trusted Root Certification Authorities"
-       [[br]]
-       \#\#"OK"
-       [[br]]
-       \#\#"Next"
-       [[br]]
-       \#\#"Finish"
-       [[br]]
-       \#\#"Yes"
-       [[br]]
-       \#\#"OK"
-
-       (b) \(user.crt)\ and \(user.key)\
-
-       These files should be installed into the server software. In Exim, this
-       can be done by adding these lines to the configuration file:
-
-==>      tls_certificate = /usr/local/etc/exim/tls_cert
-         tls_privatekey = /usr/local/etc/exim/tls_key
-
-       Then install \(user.crt)\ and \(user.key)\ under the names \(tls_cert)\
-       and \(tls_key)\ in the appropriate directory.
+A1701: Don't use a self-signed certificate today.  Use a certificate from a
+       certificate authority, whether your own private certificate authority or
+       a free CA such as Let's Encrypt.
 
+       The exim.org setup uses Let's Encrypt, using the lego tooling and a small
+       shell wrapper to let the certificates be automatically renewed via cron.
+
+       \?https://github.com/xenolf/lego?\
 
 Q1702: How can I arrange for Exim to advertise support for SMTP authentication
        only when the session is encrypted?