Remove unused/never installed libssl tools and docs and references to them

Sure deraadt

20 files changed, 17 insertions, 1267 deletions

diff --git a/src/lib/libssl/src/doc/HOWTO/certificates.txt b/src/lib/libssl/src/doc/HOWTO/certificates.txt
deleted file mode 100644
index a8a34c7abc..0000000000
--- a/src/lib/libssl/src/doc/HOWTO/certificates.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-<DRAFT!>
-                        HOWTO certificates
-
-1. Introduction
-
-How you handle certificates depend a great deal on what your role is.
-Your role can be one or several of:
-
-  - User of some client software
-  - User of some server software
-  - Certificate authority
-
-This file is for users who wish to get a certificate of their own.
-Certificate authorities should read ca.txt.
-
-In all the cases shown below, the standard configuration file, as
-compiled into openssl, will be used.  You may find it in /etc/,
-/usr/local/ssl/ or somewhere else.  The name is openssl.cnf, and
-is better described in another HOWTO <config.txt?>.  If you want to
-use a different configuration file, use the argument '-config {file}'
-with the command shown below.
-
-
-2. Relationship with keys
-
-Certificates are related to public key cryptography by containing a
-public key.  To be useful, there must be a corresponding private key
-somewhere.  With OpenSSL, public keys are easily derived from private
-keys, so before you create a certificate or a certificate request, you
-need to create a private key.
-
-Private keys are generated with 'openssl genrsa' if you want a RSA
-private key, or 'openssl gendsa' if you want a DSA private key.
-Further information on how to create private keys can be found in
-another HOWTO <keys.txt?>.  The rest of this text assumes you have
-a private key in the file privkey.pem.
-
-
-3. Creating a certificate request
-
-To create a certificate, you need to start with a certificate
-request (or, as some certificate authorities like to put
-it, "certificate signing request", since that's exactly what they do,
-they sign it and give you the result back, thus making it authentic
-according to their policies).  A certificate request can then be sent
-to a certificate authority to get it signed into a certificate, or if
-you have your own certificate authority, you may sign it yourself, or
-if you need a self-signed certificate (because you just want a test
-certificate or because you are setting up your own CA).
-
-The certificate request is created like this:
-
-  openssl req -new -key privkey.pem -out cert.csr
-
-Now, cert.csr can be sent to the certificate authority, if they can
-handle files in PEM format.  If not, use the extra argument '-outform'
-followed by the keyword for the format to use (see another HOWTO
-<formats.txt?>).  In some cases, that isn't sufficient and you will
-have to be more creative.
-
-When the certificate authority has then done the checks the need to
-do (and probably gotten payment from you), they will hand over your
-new certificate to you.
-
-Section 5 will tell you more on how to handle the certificate you
-received.
-
-
-4. Creating a self-signed test certificate
-
-If you don't want to deal with another certificate authority, or just
-want to create a test certificate for yourself.  This is similar to
-creating a certificate request, but creates a certificate instead of
-a certificate request.  This is NOT the recommended way to create a
-CA certificate, see ca.txt.
-
-  openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
-
-
-5. What to do with the certificate
-
-If you created everything yourself, or if the certificate authority
-was kind enough, your certificate is a raw DER thing in PEM format.
-Your key most definitely is if you have followed the examples above.
-However, some (most?) certificate authorities will encode them with
-things like PKCS7 or PKCS12, or something else.  Depending on your
-applications, this may be perfectly OK, it all depends on what they
-know how to decode.  If not, There are a number of OpenSSL tools to
-convert between some (most?) formats.
-
-So, depending on your application, you may have to convert your
-certificate and your key to various formats, most often also putting
-them together into one file.  The ways to do this is described in
-another HOWTO <formats.txt?>, I will just mention the simplest case.
-In the case of a raw DER thing in PEM format, and assuming that's all
-right for yor applications, simply concatenating the certificate and
-the key into a new file and using that one should be enough.  With
-some applications, you don't even have to do that.
-
-
-By now, you have your cetificate and your private key and can start
-using the software that depend on it.
-
--- 
-Richard Levitte
diff --git a/src/lib/libssl/src/doc/HOWTO/keys.txt b/src/lib/libssl/src/doc/HOWTO/keys.txt
deleted file mode 100644
index 7ae2a3a118..0000000000
--- a/src/lib/libssl/src/doc/HOWTO/keys.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-<DRAFT!>
-                        HOWTO keys
-
-1. Introduction
-
-Keys are the basis of public key algorithms and PKI.  Keys usually
-come in pairs, with one half being the public key and the other half
-being the private key.  With OpenSSL, the private key contains the
-public key information as well, so a public key doesn't need to be
-generated separately.
-
-Public keys come in several flavors, using different cryptographic
-algorithms.  The most popular ones associated with certificates are
-RSA and DSA, and this HOWTO will show how to generate each of them.
-
-
-2. To generate a RSA key
-
-A RSA key can be used both for encryption and for signing.
-
-Generating a key for the RSA algorithm is quite easy, all you have to
-do is the following:
-
-  openssl genrsa -des3 -out privkey.pem 2048
-
-With this variant, you will be prompted for a protecting password.  If
-you don't want your key to be protected by a password, remove the flag
-'-des3' from the command line above.
-
-    NOTE: if you intend to use the key together with a server
-    certificate, it may be a good thing to avoid protecting it
-    with a password, since that would mean someone would have to
-    type in the password every time the server needs to access
-    the key.
-
-The number 2048 is the size of the key, in bits.  Today, 2048 or
-higher is recommended for RSA keys, as fewer amount of bits is
-consider insecure or to be insecure pretty soon.
-
-
-3. To generate a DSA key
-
-A DSA key can be used for signing only.  This is important to keep
-in mind to know what kind of purposes a certificate request with a
-DSA key can really be used for.
-
-Generating a key for the DSA algorithm is a two-step process.  First,
-you have to generate parameters from which to generate the key:
-
-  openssl dsaparam -out dsaparam.pem 2048
-
-The number 2048 is the size of the key, in bits.  Today, 2048 or
-higher is recommended for DSA keys, as fewer amount of bits is
-consider insecure or to be insecure pretty soon.
-
-When that is done, you can generate a key using the parameters in
-question (actually, several keys can be generated from the same
-parameters):
-
-  openssl gendsa -des3 -out privkey.pem dsaparam.pem
-
-With this variant, you will be prompted for a protecting password.  If
-you don't want your key to be protected by a password, remove the flag
-'-des3' from the command line above.
-
-    NOTE: if you intend to use the key together with a server
-    certificate, it may be a good thing to avoid protecting it
-    with a password, since that would mean someone would have to
-    type in the password every time the server needs to access
-    the key.
-
--- 
-Richard Levitte
diff --git a/src/lib/libssl/src/doc/HOWTO/proxy_certificates.txt b/src/lib/libssl/src/doc/HOWTO/proxy_certificates.txt
deleted file mode 100644
index f98ec36076..0000000000
--- a/src/lib/libssl/src/doc/HOWTO/proxy_certificates.txt
+++ /dev/null
@@ -1,322 +0,0 @@
-<DRAFT!>
-                        HOWTO proxy certificates
-
-0. WARNING
-
-NONE OF THE CODE PRESENTED HERE HAVE BEEN CHECKED!  They are just an
-example to show you how things can be done.  There may be typos or
-type conflicts, and you will have to resolve them.
-
-1. Introduction
-
-Proxy certificates are defined in RFC 3820.  They are really usual
-certificates with the mandatory extension proxyCertInfo.
-
-Proxy certificates are issued by an End Entity (typically a user),
-either directly with the EE certificate as issuing certificate, or by
-extension through an already issued proxy certificate..  They are used
-to extend rights to some other entity (a computer process, typically,
-or sometimes to the user itself), so it can perform operations in the
-name of the owner of the EE certificate.
-
-See http://www.ietf.org/rfc/rfc3820.txt for more information.
-
-
-2. A warning about proxy certificates
-
-Noone seems to have tested proxy certificates with security in mind.
-Basically, to this date, it seems that proxy certificates have only
-been used in a world that's highly aware of them.  What would happen
-if an unsuspecting application is to validate a chain of certificates
-that contains proxy certificates?  It would usually consider the leaf
-to be the certificate to check for authorisation data, and since proxy
-certificates are controlled by the EE certificate owner alone, it's
-would be normal to consider what the EE certificate owner could do
-with them.
-
-subjectAltName and issuerAltName are forbidden in proxy certificates,
-and this is enforced in OpenSSL.  The subject must be the same as the
-issuer, with one commonName added on.
-
-Possible threats are, as far as has been imagined so far:
-
- - impersonation through commonName (think server certificates).
- - use of additional extensions, possibly non-standard ones used in
-   certain environments, that would grant extra or different
-   authorisation rights.
-
-For this reason, OpenSSL requires that the use of proxy certificates
-be explicitely allowed.  Currently, this can be done using the
-following methods:
-
- - if the application calls X509_verify_cert() itself, it can do the
-   following prior to that call (ctx is the pointer passed in the call
-   to X509_verify_cert()):
-
-        X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS);
-
- - in all other cases, proxy certificate validation can be enabled
-   before starting the application by setting the envirnoment variable
-   OPENSSL_ALLOW_PROXY_CERTS with some non-empty value.
-
-There are thoughts to allow proxy certificates with a line in the
-default openssl.cnf, but that's still in the future.
-
-
-3. How to create proxy cerificates
-
-It's quite easy to create proxy certificates, by taking advantage of
-the lack of checks of the 'openssl x509' application (*ahem*).  But
-first, you need to create a configuration section that contains a
-definition of the proxyCertInfo extension, a little like this:
-
-  [ v3_proxy ]
-  # A proxy certificate MUST NEVER be a CA certificate.
-  basicConstraints=CA:FALSE
-
-  # Usual authority key ID
-  authorityKeyIdentifier=keyid,issuer:always
-
-  # Now, for the extension that marks this certificate as a proxy one
-  proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:1,policy:text:AB
-
-It's also possible to give the proxy extension in a separate section:
-
-  proxyCertInfo=critical,@proxy_ext
-
-  [ proxy_ext ]
-  language=id-ppl-anyLanguage
-  pathlen=0
-  policy=text:BC
-
-The policy value has a specific syntax, {syntag}:{string}, where the
-syntag determines what will be done with the string.  The recognised
-syntags are as follows:
-
-  text  indicates that the string is simply the bytes, not
-        encoded in any kind of way:
-
-                policy=text:räksmörgås
-
-        Previous versions of this design had a specific tag
-        for UTF-8 text.  However, since the bytes are copied
-        as-is anyway, there's no need for it.  Instead, use
-        the text: tag, like this:
-
-                policy=text:räksmörgås
-
-  hex   indicates the string is encoded in hex, with colons
-        between each byte (every second hex digit):
-
-                policy=hex:72:E4:6B:73:6D:F6:72:67:E5:73
-
-        Previous versions of this design had a tag to insert a
-        complete DER blob.  However, the only legal use for
-        this would be to surround the bytes that would go with
-        the hex: tag with what's needed to construct a correct
-        OCTET STRING.  Since hex: does that, the DER tag felt
-        superfluous, and was therefore removed.
-
-  file  indicates that the text of the policy should really be
-        taken from a file.  The string is then really a file
-        name.  This is useful for policies that are large
-        (more than a few of lines) XML documents, for example.
-
-The 'policy' setting can be split up in multiple lines like this:
-
-  0.policy=This is
-  1.polisy= a multi-
-  2.policy=line policy.
-
-NOTE: the proxy policy value is the part that determines the rights
-granted to the process using the proxy certificate.  The value is
-completely dependent on the application reading and interpretting it!
-
-Now that you have created an extension section for your proxy
-certificate, you can now easily create a proxy certificate like this:
-
-  openssl req -new -config openssl.cnf \
-          -out proxy.req -keyout proxy.key
-  openssl x509 -req -CAcreateserial -in proxy.req -days 7 \
-          -out proxy.crt -CA user.crt -CAkey user.key \
-          -extfile openssl.cnf -extensions v3_proxy
-
-It's just as easy to create a proxy certificate using another proxy
-certificate as issuer (note that I'm using a different configuration
-section for it):
-
-  openssl req -new -config openssl.cnf \
-          -out proxy2.req -keyout proxy2.key
-  openssl x509 -req -CAcreateserial -in proxy2.req -days 7 \
-          -out proxy2.crt -CA proxy.crt -CAkey proxy.key \
-          -extfile openssl.cnf -extensions v3_proxy2
-
-
-4. How to have your application interpret the policy?
-
-The basic way to interpret proxy policies is to prepare some default
-rights, then do a check of the proxy certificate against the a chain
-of proxy certificates, user certificate and CA certificates, and see
-what rights came out by the end.  Sounds easy, huh?  It almost is.
-
-The slightly complicated part is how to pass data between your
-application and the certificate validation procedure.
-
-You need the following ingredients:
-
- - a callback routing that will be called for every certificate that's
-   validated.  It will be called several times for each certificates,
-   so you must be attentive to when it's a good time to do the proxy
-   policy interpretation and check, as well as to fill in the defaults
-   when the EE certificate is checked.
-
- - a structure of data that's shared between your application code and
-   the callback.
-
- - a wrapper function that sets it all up.
-
- - an ex_data index function that creates an index into the generic
-   ex_data store that's attached to an X509 validation context.
-
-This is some cookbook code for you to fill in:
-
-  /* In this example, I will use a view of granted rights as a bit
-     array, one bit for each possible right.  */
-  typedef struct your_rights {
-    unsigned char rights[total_rights / 8];
-  } YOUR_RIGHTS;
-
-  /* The following procedure will create an index for the ex_data
-     store in the X509 validation context the first time it's called.
-     Subsequent calls will return the same index.  */
-  static int get_proxy_auth_ex_data_idx(void)
-  {
-    static volatile int idx = -1;
-    if (idx < 0)
-      {
-        CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
-        if (idx < 0)
-          {
-            idx = X509_STORE_CTX_get_ex_new_index(0,
-                                                  "for verify callback",
-                                                  NULL,NULL,NULL);
-          }
-        CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
-      }
-    return idx;
-  }
-
-  /* Callback to be given to the X509 validation procedure.  */
-  static int verify_callback(int ok, X509_STORE_CTX *ctx)
-  {
-    if (ok == 1) /* It's REALLY important you keep the proxy policy
-                    check within this secion.  It's important to know
-                    that when ok is 1, the certificates are checked
-                    from top to bottom.  You get the CA root first,
-                    followed by the possible chain of intermediate
-                    CAs, followed by the EE certificate, followed by
-                    the possible proxy certificates.  */
-      {
-        X509 *xs = ctx->current_cert;
-
-        if (xs->ex_flags & EXFLAG_PROXY)
-          {
-            YOUR_RIGHTS *rights =
-              (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx,
-                get_proxy_auth_ex_data_idx());
-            PROXY_CERT_INFO_EXTENSION *pci =
-              X509_get_ext_d2i(xs, NID_proxyCertInfo, NULL, NULL);
-
-            switch (OBJ_obj2nid(pci->proxyPolicy->policyLanguage))
-              {
-              case NID_Independent:
-                /* Do whatever you need to grant explicit rights to
-                   this particular proxy certificate, usually by
-                   pulling them from some database.  If there are none
-                   to be found, clear all rights (making this and any
-                   subsequent proxy certificate void of any rights).
-                */
-                memset(rights->rights, 0, sizeof(rights->rights));
-                break;
-              case NID_id_ppl_inheritAll:
-                /* This is basically a NOP, we simply let the current
-                   rights stand as they are. */
-                break;
-              default:
-                /* This is usually the most complex section of code.
-                   You really do whatever you want as long as you
-                   follow RFC 3820.  In the example we use here, the
-                   simplest thing to do is to build another, temporary
-                   bit array and fill it with the rights granted by
-                   the current proxy certificate, then use it as a
-                   mask on the accumulated rights bit array, and
-                   voilà, you now have a new accumulated rights bit
-                   array.  */
-                {
-                  int i;
-                  YOUR_RIGHTS tmp_rights;
-                  memset(tmp_rights.rights, 0, sizeof(tmp_rights.rights));
-
-                  /* process_rights() is supposed to be a procedure
-                     that takes a string and it's length, interprets
-                     it and sets the bits in the YOUR_RIGHTS pointed
-                     at by the third argument.  */
-                  process_rights((char *) pci->proxyPolicy->policy->data,
-                                 pci->proxyPolicy->policy->length,
-                                 &tmp_rights);
-
-                  for(i = 0; i < total_rights / 8; i++)
-                    rights->rights[i] &= tmp_rights.rights[i];
-                }
-                break;
-              }
-            PROXY_CERT_INFO_EXTENSION_free(pci);
-          }
-        else if (!(xs->ex_flags & EXFLAG_CA))
-          {
-            /* We have a EE certificate, let's use it to set default!
-            */
-            YOUR_RIGHTS *rights =
-              (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx,
-                get_proxy_auth_ex_data_idx());
-
-            /* The following procedure finds out what rights the owner
-               of the current certificate has, and sets them in the
-               YOUR_RIGHTS structure pointed at by the second
-               argument.  */
-            set_default_rights(xs, rights);
-          }
-      }
-    return ok;
-  }
-
-  static int my_X509_verify_cert(X509_STORE_CTX *ctx,
-                                 YOUR_RIGHTS *needed_rights)
-  {
-    int i;
-    int (*save_verify_cb)(int ok,X509_STORE_CTX *ctx) = ctx->verify_cb;
-    YOUR_RIGHTS rights;
-
-    X509_STORE_CTX_set_verify_cb(ctx, verify_callback);
-    X509_STORE_CTX_set_ex_data(ctx, get_proxy_auth_ex_data_idx(), &rights);
-    X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS);
-    ok = X509_verify_cert(ctx);
-
-    if (ok == 1)
-      {
-        ok = check_needed_rights(rights, needed_rights);
-      }
-
-    X509_STORE_CTX_set_verify_cb(ctx, save_verify_cb);
-
-    return ok;
-  }
-
-If you use SSL or TLS, you can easily set up a callback to have the
-certificates checked properly, using the code above:
-
-  SSL_CTX_set_cert_verify_callback(s_ctx, my_X509_verify_cert, &needed_rights);
-
-
--- 
-Richard Levitte
diff --git a/src/lib/libssl/src/doc/README b/src/lib/libssl/src/doc/README
deleted file mode 100644
index 6ecc14d994..0000000000
--- a/src/lib/libssl/src/doc/README
+++ /dev/null
@@ -1,12 +0,0 @@
-
- apps/openssl.pod .... Documentation of OpenSSL `openssl' command
- crypto/crypto.pod ... Documentation of OpenSSL crypto.h+libcrypto.a
- ssl/ssl.pod ......... Documentation of OpenSSL ssl.h+libssl.a
- openssl.txt ......... Assembled documentation files for OpenSSL [not final]
- ssleay.txt .......... Assembled documentation of ancestor SSLeay [obsolete]
- standards.txt ....... Assembled pointers to standards, RFCs or internet drafts
-                       that are related to OpenSSL.
-
- An archive of HTML documents for the SSLeay library is available from
- http://www.columbia.edu/~ariel/ssleay/
-
diff --git a/src/lib/libssl/src/doc/apps/CA.pl.pod b/src/lib/libssl/src/doc/apps/CA.pl.pod
deleted file mode 100644
index d326101cde..0000000000
--- a/src/lib/libssl/src/doc/apps/CA.pl.pod
+++ /dev/null
@@ -1,179 +0,0 @@
-
-=pod
-
-=head1 NAME
-
-CA.pl - friendlier interface for OpenSSL certificate programs
-
-=head1 SYNOPSIS
-
-B<CA.pl>
-[B<-?>]
-[B<-h>]
-[B<-help>]
-[B<-newcert>]
-[B<-newreq>]
-[B<-newreq-nodes>]
-[B<-newca>]
-[B<-xsign>]
-[B<-sign>]
-[B<-signreq>]
-[B<-signcert>]
-[B<-verify>]
-[B<files>]
-
-=head1 DESCRIPTION
-
-The B<CA.pl> script is a perl script that supplies the relevant command line
-arguments to the B<openssl> command for some common certificate operations.
-It is intended to simplify the process of certificate creation and management
-by the use of some simple options.
-
-=head1 COMMAND OPTIONS
-
-=over 4
-
-=item B<?>, B<-h>, B<-help>
-
-prints a usage message.
-
-=item B<-newcert>
-
-creates a new self signed certificate. The private key is written to the file
-"newkey.pem" and the request written to the file "newreq.pem".
-
-=item B<-newreq>
-
-creates a new certificate request. The private key is written to the file
-"newkey.pem" and the request written to the file "newreq.pem".
-
-=item B<-newreq-nodes>
-
-is like B<-newreq> except that the private key will not be encrypted.
-
-=item B<-newca>
-
-creates a new CA hierarchy for use with the B<ca> program (or the B<-signcert>
-and B<-xsign> options). The user is prompted to enter the filename of the CA
-certificates (which should also contain the private key) or by hitting ENTER
-details of the CA will be prompted for. The relevant files and directories
-are created in a directory called "demoCA" in the current directory.
-
-=item B<-pkcs12>
-
-create a PKCS#12 file containing the user certificate, private key and CA
-certificate. It expects the user certificate and private key to be in the
-file "newcert.pem" and the CA certificate to be in the file demoCA/cacert.pem,
-it creates a file "newcert.p12". This command can thus be called after the
-B<-sign> option. The PKCS#12 file can be imported directly into a browser.
-If there is an additional argument on the command line it will be used as the
-"friendly name" for the certificate (which is typically displayed in the browser
-list box), otherwise the name "My Certificate" is used.
-
-=item B<-sign>, B<-signreq>, B<-xsign>
-
-calls the B<ca> program to sign a certificate request. It expects the request
-to be in the file "newreq.pem". The new certificate is written to the file
-"newcert.pem" except in the case of the B<-xsign> option when it is written
-to standard output.
-
-
-=item B<-signCA>
-
-this option is the same as the B<-signreq> option except it uses the configuration
-file section B<v3_ca> and so makes the signed request a valid CA certificate. This
-is useful when creating intermediate CA from a root CA.
-
-=item B<-signcert>
-
-this option is the same as B<-sign> except it expects a self signed certificate
-to be present in the file "newreq.pem".
-
-=item B<-verify>
-
-verifies certificates against the CA certificate for "demoCA". If no certificates
-are specified on the command line it tries to verify the file "newcert.pem". 
-
-=item B<files>
-
-one or more optional certificate file names for use with the B<-verify> command.
-
-=back
-
-=head1 EXAMPLES
-
-Create a CA hierarchy:
-
- CA.pl -newca
-
-Complete certificate creation example: create a CA, create a request, sign
-the request and finally create a PKCS#12 file containing it.
-
- CA.pl -newca
- CA.pl -newreq
- CA.pl -signreq
- CA.pl -pkcs12 "My Test Certificate"
-
-=head1 DSA CERTIFICATES
-
-Although the B<CA.pl> creates RSA CAs and requests it is still possible to
-use it with DSA certificates and requests using the L<req(1)|req(1)> command
-directly. The following example shows the steps that would typically be taken.
-
-Create some DSA parameters:
-
- openssl dsaparam -out dsap.pem 1024
-
-Create a DSA CA certificate and private key:
-
- openssl req -x509 -newkey dsa:dsap.pem -keyout cacert.pem -out cacert.pem
-
-Create the CA directories and files:
-
- CA.pl -newca
-
-enter cacert.pem when prompted for the CA file name.
-
-Create a DSA certificate request and private key (a different set of parameters
-can optionally be created first):
-
- openssl req -out newreq.pem -newkey dsa:dsap.pem 
-
-Sign the request:
-
- CA.pl -signreq
-
-=head1 NOTES
-
-Most of the filenames mentioned can be modified by editing the B<CA.pl> script.
-
-If the demoCA directory already exists then the B<-newca> command will not
-overwrite it and will do nothing. This can happen if a previous call using
-the B<-newca> option terminated abnormally. To get the correct behaviour
-delete the demoCA directory if it already exists.
-
-Under some environments it may not be possible to run the B<CA.pl> script
-directly (for example Win32) and the default configuration file location may
-be wrong. In this case the command:
-
- perl -S CA.pl
-
-can be used and the B<OPENSSL_CONF> environment variable changed to point to 
-the correct path of the configuration file "openssl.cnf".
-
-The script is intended as a simple front end for the B<openssl> program for use
-by a beginner. Its behaviour isn't always what is wanted. For more control over the
-behaviour of the certificate commands call the B<openssl> command directly.
-
-=head1 ENVIRONMENT VARIABLES
-
-The variable B<OPENSSL_CONF> if defined allows an alternative configuration
-file location to be specified, it should contain the full path to the
-configuration file, not just its directory.
-
-=head1 SEE ALSO
-
-L<x509(1)|x509(1)>, L<ca(1)|ca(1)>, L<req(1)|req(1)>, L<pkcs12(1)|pkcs12(1)>,
-L<config(5)|config(5)>
-
-=cut
diff --git a/src/lib/libssl/src/doc/apps/tsget.pod b/src/lib/libssl/src/doc/apps/tsget.pod
deleted file mode 100644
index 56db985c4b..0000000000
--- a/src/lib/libssl/src/doc/apps/tsget.pod
+++ /dev/null
@@ -1,194 +0,0 @@
-=pod
-
-=head1 NAME
-
-tsget - Time Stamping HTTP/HTTPS client
-
-=head1 SYNOPSIS
-
-B<tsget>
-B<-h> server_url
-[B<-e> extension]
-[B<-o> output]
-[B<-v>]
-[B<-d>]
-[B<-k> private_key.pem]
-[B<-p> key_password]
-[B<-c> client_cert.pem]
-[B<-C> CA_certs.pem]
-[B<-P> CA_path]
-[B<-r> file:file...]
-[B<-g> EGD_socket]
-[request]...
-
-=head1 DESCRIPTION
-
-The B<tsget> command can be used for sending a time stamp request, as
-specified in B<RFC 3161>, to a time stamp server over HTTP or HTTPS and storing
-the time stamp response in a file. This tool cannot be used for creating the
-requests and verifying responses, you can use the OpenSSL B<ts(1)> command to
-do that. B<tsget> can send several requests to the server without closing
-the TCP connection if more than one requests are specified on the command
-line.
-
-The tool sends the following HTTP request for each time stamp request:
-
-        POST url HTTP/1.1
-        User-Agent: OpenTSA tsget.pl/<version>
-        Host: <host>:<port>
-        Pragma: no-cache
-        Content-Type: application/timestamp-query
-        Accept: application/timestamp-reply
-        Content-Length: length of body
-
-        ...binary request specified by the user...
-
-B<tsget> expects a response of type application/timestamp-reply, which is
-written to a file without any interpretation.
-
-=head1 OPTIONS
-
-=over 4
-
-=item B<-h> server_url
-
-The URL of the HTTP/HTTPS server listening for time stamp requests.
-
-=item B<-e> extension
-
-If the B<-o> option is not given this argument specifies the extension of the
-output files. The base name of the output file will be the same as those of
-the input files. Default extension is '.tsr'. (Optional)
-
-=item B<-o> output
-
-This option can be specified only when just one request is sent to the
-server. The time stamp response will be written to the given output file. '-'
-means standard output. In case of multiple time stamp requests or the absence
-of this argument the names of the output files will be derived from the names
-of the input files and the default or specified extension argument. (Optional)
-
-=item B<-v>
-
-The name of the currently processed request is printed on standard
-error. (Optional)
-
-=item B<-d>
-
-Switches on verbose mode for the underlying B<curl> library. You can see
-detailed debug messages for the connection. (Optional)
-
-=item B<-k> private_key.pem
-
-(HTTPS) In case of certificate-based client authentication over HTTPS
-<private_key.pem> must contain the private key of the user. The private key
-file can optionally be protected by a passphrase. The B<-c> option must also
-be specified. (Optional)
-
-=item B<-p> key_password
-
-(HTTPS) Specifies the passphrase for the private key specified by the B<-k>
-argument. If this option is omitted and the key is passphrase protected B<tsget>
-will ask for it. (Optional)
-
-=item B<-c> client_cert.pem
-
-(HTTPS) In case of certificate-based client authentication over HTTPS
-<client_cert.pem> must contain the X.509 certificate of the user.  The B<-k>
-option must also be specified. If this option is not specified no
-certificate-based client authentication will take place. (Optional)
-
-=item B<-C> CA_certs.pem
-
-(HTTPS) The trusted CA certificate store. The certificate chain of the peer's
-certificate must include one of the CA certificates specified in this file.
-Either option B<-C> or option B<-P> must be given in case of HTTPS. (Optional)
-
-=item B<-P> CA_path
-
-(HTTPS) The path containing the trusted CA certificates to verify the peer's
-certificate. The directory must be prepared with the B<c_rehash>
-OpenSSL utility. Either option B<-C> or option B<-P> must be given in case of
-HTTPS. (Optional)
-
-=item B<-rand> file:file...
-
-The files containing random data for seeding the random number
-generator. Multiple files can be specified, the separator is B<;> for
-MS-Windows, B<,> for VMS and B<:> for all other platforms. (Optional)
-
-=item B<-g> EGD_socket
-
-The name of an EGD socket to get random data from. (Optional)
-
-=item [request]...
-
-List of files containing B<RFC 3161> DER-encoded time stamp requests. If no
-requests are specified only one request will be sent to the server and it will be
-read from the standard input. (Optional)
-
-=back
-
-=head1 ENVIRONMENT VARIABLES
-
-The B<TSGET> environment variable can optionally contain default
-arguments. The content of this variable is added to the list of command line
-arguments.
-
-=head1 EXAMPLES
-
-The examples below presume that B<file1.tsq> and B<file2.tsq> contain valid
-time stamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
-and at port 8443 for HTTPS requests, the TSA service is available at the /tsa
-absolute path.
-
-Get a time stamp response for file1.tsq over HTTP, output is written to 
-file1.tsr:
-
-  tsget -h http://tsa.opentsa.org:8080/tsa file1.tsq
-
-Get a time stamp response for file1.tsq and file2.tsq over HTTP showing
-progress, output is written to file1.reply and file2.reply respectively:
-
-  tsget -h http://tsa.opentsa.org:8080/tsa -v -e .reply \
-        file1.tsq file2.tsq
-
-Create a time stamp request, write it to file3.tsq, send it to the server and
-write the response to file3.tsr:
-
-  openssl ts -query -data file3.txt -cert | tee file3.tsq \
-        | tsget -h http://tsa.opentsa.org:8080/tsa \
-        -o file3.tsr
-
-Get a time stamp response for file1.tsq over HTTPS without client
-authentication:
-
-  tsget -h https://tsa.opentsa.org:8443/tsa \
-        -C cacerts.pem file1.tsq
-
-Get a time stamp response for file1.tsq over HTTPS with certificate-based
-client authentication (it will ask for the passphrase if client_key.pem is
-protected):
-
-  tsget -h https://tsa.opentsa.org:8443/tsa -C cacerts.pem \
-        -k client_key.pem -c client_cert.pem file1.tsq
-
-You can shorten the previous command line if you make use of the B<TSGET>
-environment variable. The following commands do the same as the previous
-example:
-
-  TSGET='-h https://tsa.opentsa.org:8443/tsa -C cacerts.pem \
-        -k client_key.pem -c client_cert.pem'
-  export TSGET
-  tsget file1.tsq
-
-=head1 AUTHOR
-
-Zoltan Glozik <zglozik@opentsa.org>, OpenTSA project (http://www.opentsa.org)
-
-=head1 SEE ALSO
-
-L<openssl(1)|openssl(1)>, L<ts(1)|ts(1)>, L<curl(1)|curl(1)>, 
-B<RFC 3161>
-
-=cut
diff --git a/src/lib/libssl/src/doc/apps/verify.pod b/src/lib/libssl/src/doc/apps/verify.pod
index da683004bd..f1d5384b9a 100644
--- a/src/lib/libssl/src/doc/apps/verify.pod
+++ b/src/lib/libssl/src/doc/apps/verify.pod
@@ -43,8 +43,7 @@ The B<verify> command verifies certificate chains.
 A directory of trusted certificates. The certificates should have names
 of the form: hash.0 or have symbolic links to them of this
 form ("hash" is the hashed certificate subject name: see the B<-hash> option
-of the B<x509> utility). Under Unix the B<c_rehash> script will automatically
-create symbolic links to a directory of certificates.
+of the B<x509> utility).
 
 =item B<-CAfile file>
 
diff --git a/src/lib/libssl/src/doc/apps/x509.pod b/src/lib/libssl/src/doc/apps/x509.pod
index d2d9eb812a..314018f086 100644
--- a/src/lib/libssl/src/doc/apps/x509.pod
+++ b/src/lib/libssl/src/doc/apps/x509.pod
@@ -856,6 +856,6 @@ The hash algorithm used in the B<-subject_hash> and B<-issuer_hash> options
 before OpenSSL 1.0.0 was based on the deprecated MD5 algorithm and the encoding
 of the distinguished name. In OpenSSL 1.0.0 and later it is based on a
 canonical version of the DN using SHA1. This means that any directories using
-the old form must have their links rebuilt using B<c_rehash> or similar. 
+the old form must have their links rebuilt.
 
 =cut
diff --git a/src/lib/libssl/src/doc/c-indentation.el b/src/lib/libssl/src/doc/c-indentation.el
deleted file mode 100644
index 90861d3979..0000000000
--- a/src/lib/libssl/src/doc/c-indentation.el
+++ /dev/null
@@ -1,45 +0,0 @@
-; This Emacs Lisp file defines a C indentation style that closely
-; follows most aspects of the one that is used throughout SSLeay,
-; and hence in OpenSSL.
-; 
-; This definition is for the "CC mode" package, which is the default
-; mode for editing C source files in Emacs 20, not for the older
-; c-mode.el (which was the default in less recent releaes of Emacs 19).
-;
-; Copy the definition in your .emacs file or use M-x eval-buffer.
-; To activate this indentation style, visit a C file, type
-; M-x c-set-style <RET> (or C-c . for short), and enter "eay".
-; To toggle the auto-newline feature of CC mode, type C-c C-a.
-;
-; Apparently statement blocks that are not introduced by a statement
-; such as "if" and that are not the body of a function cannot
-; be handled too well by CC mode with this indentation style,
-; so you have to indent them manually (you can use C-q tab).
-; 
-; For suggesting improvements, please send e-mail to bodo@openssl.org.
-
-(c-add-style "eay"
-             '((c-basic-offset . 8)
-               (indent-tabs-mode . t)
-               (c-comment-only-line-offset . 0)
-               (c-hanging-braces-alist)
-               (c-offsets-alist . ((defun-open . +)
-                                   (defun-block-intro . 0)
-                                   (class-open . +)
-                                   (class-close . +)
-                                   (block-open . 0)
-                                   (block-close . 0)
-                                   (substatement-open . +)
-                                   (statement . 0)
-                                   (statement-block-intro . 0)
-                                   (statement-case-open . +)
-                                   (statement-case-intro . +)
-                                   (case-label . -)
-                                   (label . -)
-                                   (arglist-cont-nonempty . +)
-                                   (topmost-intro . -)
-                                   (brace-list-close . 0)
-                                   (brace-list-intro . 0)
-                                   (brace-list-open . +)
-                                   ))))
-
diff --git a/src/lib/libssl/src/doc/fingerprints.txt b/src/lib/libssl/src/doc/fingerprints.txt
deleted file mode 100644
index 7d05a85594..0000000000
--- a/src/lib/libssl/src/doc/fingerprints.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-                              Fingerprints
-
-OpenSSL releases are signed with PGP/GnuPG keys.  You can find the
-signatures in separate files in the same location you find the
-distributions themselves.  The normal file name is the same as the
-distribution file, with '.asc' added.  For example, the signature for
-the distribution of OpenSSL 0.9.7f, openssl-0.9.7f.tar.gz, is found in
-the file openssl-0.9.7f.tar.gz.asc.
-
-The following is the list of fingerprints for the keys that are
-currently in use (have been used since summer 2004) to sign OpenSSL
-distributions:
-
-pub   1024D/F709453B 2003-10-20
-      Key fingerprint = C4CA B749 C34F 7F4C C04F  DAC9 A7AF 9E78 F709 453B
-uid                  Richard Levitte <richard@levitte.org>
-uid                  Richard Levitte <levitte@openssl.org>
-uid                  Richard Levitte <levitte@lp.se>
-
-pub   2048R/F295C759 1998-12-13
-      Key fingerprint = D0 5D 8C 61 6E 27 E6 60  41 EC B1 B8 D5 7E E5 97
-uid                  Dr S N Henson <shenson@drh-consultancy.demon.co.uk>
-
-pub   1024R/49A563D9 1997-02-24
-      Key fingerprint = 7B 79 19 FA 71 6B 87 25  0E 77 21 E5 52 D9 83 BF
-uid                  Mark Cox <mjc@redhat.com>
-uid                  Mark Cox <mark@awe.com>
-uid                  Mark Cox <mjc@apache.org>
-
-pub   1024R/26BB437D 1997-04-28
-      Key fingerprint = 00 C9 21 8E D1 AB 70 37  DD 67 A2 3A 0A 6F 8D A5
-uid                  Ralf S. Engelschall <rse@engelschall.com>
-
-pub   1024R/9C58A66D 1997-04-03
-      Key fingerprint = 13 D0 B8 9D 37 30 C3 ED  AC 9C 24 7D 45 8C 17 67
-uid                  jaenicke@openssl.org
-uid                  Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>
-
-pub   1024D/2118CF83 1998-07-13
-      Key fingerprint = 7656 55DE 62E3 96FF 2587  EB6C 4F6D E156 2118 CF83
-uid                  Ben Laurie <ben@thebunker.net>
-uid                  Ben Laurie <ben@cryptix.org>
-uid                  Ben Laurie <ben@algroup.co.uk>
-sub   4096g/1F5143E7 1998-07-13
-
-pub   1024R/5A6A9B85 1994-03-22
-      Key fingerprint = C7 AC 7E AD 56 6A 65 EC  F6 16 66 83 7E 86 68 28
-uid                  Bodo Moeller <2005@bmoeller.de>
-uid                  Bodo Moeller <2003@bmoeller.de>
-uid                  Bodo Moeller <2004@bmoeller.de>
-uid                  Bodo Moeller <bmoeller@acm.org>
-uid                  Bodo Moeller <bodo@openssl.org>
-uid                  Bodo Moeller <bm@ulf.mali.sub.org>
-uid                  Bodo Moeller <3moeller@informatik.uni-hamburg.de>
-uid                  Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de>
-uid                  Bodo Moeller <3moeller@rzdspc5.informatik.uni-hamburg.de>
-
diff --git a/src/lib/libssl/src/doc/openssl-shared.txt b/src/lib/libssl/src/doc/openssl-shared.txt
deleted file mode 100644
index 5cf84a054f..0000000000
--- a/src/lib/libssl/src/doc/openssl-shared.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-The OpenSSL  shared libraries are often installed in a directory like
-/usr/local/ssl/lib.
-
-If this directory is not in a standard system path for dynamic/shared
-libraries, then you will have problems linking and executing
-applications that use OpenSSL libraries UNLESS:
-
-* you link with static (archive) libraries.  If you are truly
-  paranoid about security, you should use static libraries.
-* you use the GNU libtool code during linking
-  (http://www.gnu.org/software/libtool/libtool.html)
-* you use pkg-config during linking (this requires that
-  PKG_CONFIG_PATH includes the path to the OpenSSL shared
-  library directory), and make use of -R or -rpath.
-  (http://www.freedesktop.org/software/pkgconfig/)
-* you specify the system-wide link path via a command such
-  as crle(1) on Solaris systems.
-* you add the OpenSSL shared library directory to /etc/ld.so.conf
-  and run ldconfig(8) on Linux systems.
-* you define the LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH (HP),
-  DYLD_LIBRARY_PATH (MacOS X) or PATH (Cygwin and DJGPP)
-  environment variable and add the OpenSSL shared library
-  directory to it.
-
-One common tool to check the dynamic dependencies of an executable
-or dynamic library is ldd(1) on most UNIX systems.
-
-See any operating system documentation and manpages about shared
-libraries for your version of UNIX.  The following manpages may be
-helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP],
-ldd(1), crle(1) [Solaris], pldd(1) [Solaris], ldconfig(8) [Linux],
-chatr(1) [HP].
diff --git a/src/lib/libssl/src/doc/openssl_button.gif b/src/lib/libssl/src/doc/openssl_button.gif
deleted file mode 100644
index 3d3c90c9f8..0000000000
--- a/src/lib/libssl/src/doc/openssl_button.gif
+++ /dev/null
diff --git a/src/lib/libssl/src/doc/openssl_button.html b/src/lib/libssl/src/doc/openssl_button.html
deleted file mode 100644
index 44c91bd3d0..0000000000
--- a/src/lib/libssl/src/doc/openssl_button.html
+++ /dev/null
@@ -1,7 +0,0 @@
-
-<!-- the `Includes OpenSSL Cryptogaphy Software' button      -->
-<!-- freely usable by any application linked against OpenSSL -->
-<a   href="http://www.openssl.org/">
-<img src="openssl_button.gif" 
-     width=102 height=47 border=0></a>
-
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
index de01065285..cd78dd285f 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
@@ -40,7 +40,6 @@ If more than one CA certificate with the same name hash value exist, the
 extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search
 is performed in the ordering of the extension number, regardless of other
 properties of the certificates.
-Use the B<c_rehash> utility to create the necessary links.
 
 The certificates in B<CApath> are only looked up when required, e.g. when
 building the certificate chain or when actually performing the verification
@@ -92,7 +91,21 @@ Prepare the directory /some/where/certs containing several CA certificates
 for use as B<CApath>:
 
  cd /some/where/certs
- c_rehash .
+ rm -f *.[0-9]* *.r[0-9]*
+ for c in *.pem; do
+    [ "$c" = "*.pem" ] && continue
+    hash=$(openssl x509 -noout -hash -in "$c")
+    if egrep -q -- '-BEGIN( X509 | TRUSTED | )CERTIFICATE-' "$c"; then
+      suf=0
+      while [ -e $hash.$suf ]; do suf=$(( $suf + 1 )); done
+      ln -s "$c" $hash.$suf
+    fi
+    if egrep -q -- '-BEGIN X509 CRL-' "$c"; then
+      suf=0
+      while [ -e $hash.r$suf ]; do suf=$(( $suf + 1 )); done
+      ln -s "$c" $hash.r$suf
+    fi
+  done
 
 =head1 RETURN VALUES
 
diff --git a/src/lib/libssl/src/tools/c89.sh b/src/lib/libssl/src/tools/c89.sh
deleted file mode 100644
index b25c9fda2d..0000000000
--- a/src/lib/libssl/src/tools/c89.sh
+++ /dev/null
@@ -1,15 +0,0 @@
-#!/bin/sh -k
-#
-# Re-order arguments so that -L comes first
-#
-opts=""
-lopts=""
-        
-for arg in $* ; do
-  case $arg in
-    -L*) lopts="$lopts $arg" ;;
-    *) opts="$opts $arg" ;;
-  esac
-done
-
-c89 $lopts $opts
diff --git a/src/lib/libssl/src/tools/c_hash b/src/lib/libssl/src/tools/c_hash
deleted file mode 100644
index 5e0a908175..0000000000
--- a/src/lib/libssl/src/tools/c_hash
+++ /dev/null
@@ -1,9 +0,0 @@
-#!/bin/sh
-# print out the hash values 
-#
-
-for i in $*
-do
-        h=`openssl x509 -hash -noout -in $i`
-        echo "$h.0 => $i"
-done
diff --git a/src/lib/libssl/src/tools/c_info b/src/lib/libssl/src/tools/c_info
deleted file mode 100644
index 0e1e633b6f..0000000000
--- a/src/lib/libssl/src/tools/c_info
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-#
-# print the subject
-#
-
-for i in $*
-do
-        n=`openssl x509 -subject -issuer -enddate -noout -in $i`
-        echo "$i"
-        echo "$n"
-        echo "--------"
-done
diff --git a/src/lib/libssl/src/tools/c_issuer b/src/lib/libssl/src/tools/c_issuer
deleted file mode 100644
index 55821ab740..0000000000
--- a/src/lib/libssl/src/tools/c_issuer
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-#
-# print out the issuer
-#
-
-for i in $*
-do
-        n=`openssl x509 -issuer -noout -in $i`
-        echo "$i        $n"
-done
diff --git a/src/lib/libssl/src/tools/c_name b/src/lib/libssl/src/tools/c_name
deleted file mode 100644
index 28800c0b30..0000000000
--- a/src/lib/libssl/src/tools/c_name
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-#
-# print the subject
-#
-
-for i in $*
-do
-        n=`openssl x509 -subject -noout -in $i`
-        echo "$i        $n"
-done
diff --git a/src/lib/libssl/src/tools/c_rehash.in b/src/lib/libssl/src/tools/c_rehash.in
deleted file mode 100644
index bfc4a69ed4..0000000000
--- a/src/lib/libssl/src/tools/c_rehash.in
+++ /dev/null
@@ -1,180 +0,0 @@
-#!/usr/local/bin/perl
-
-
-# Perl c_rehash script, scan all files in a directory
-# and add symbolic links to their hash values.
-
-my $openssl;
-
-my $dir;
-my $prefix;
-
-if(defined $ENV{OPENSSL}) {
-        $openssl = $ENV{OPENSSL};
-} else {
-        $openssl = "openssl";
-        $ENV{OPENSSL} = $openssl;
-}
-
-my $pwd;
-eval "require Cwd";
-if (defined(&Cwd::getcwd)) {
-        $pwd=Cwd::getcwd();
-} else {
-        $pwd=`pwd`; chomp($pwd);
-}
-my $path_delim = ($pwd =~ /^[a-z]\:/i) ? ';' : ':'; # DOS/Win32 or Unix delimiter?
-
-$ENV{PATH} = "$prefix/bin" . ($ENV{PATH} ? $path_delim . $ENV{PATH} : ""); # prefix our path
-
-if(! -x $openssl) {
-        my $found = 0;
-        foreach (split /$path_delim/, $ENV{PATH}) {
-                if(-x "$_/$openssl") {
-                        $found = 1;
-                        $openssl = "$_/$openssl";
-                        last;
-                }       
-        }
-        if($found == 0) {
-                print STDERR "c_rehash: rehashing skipped ('openssl' program not available)\n";
-                exit 0;
-        }
-}
-
-if(@ARGV) {
-        @dirlist = @ARGV;
-} elsif($ENV{SSL_CERT_DIR}) {
-        @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
-} else {
-        $dirlist[0] = "$dir/certs";
-}
-
-if (-d $dirlist[0]) {
-        chdir $dirlist[0];
-        $openssl="$pwd/$openssl" if (!-x $openssl);
-        chdir $pwd;
-}
-
-foreach (@dirlist) {
-        if(-d $_ and -w $_) {
-                hash_dir($_);
-        }
-}
-
-sub hash_dir {
-        my %hashlist;
-        print "Doing $_[0]\n";
-        chdir $_[0];
-        opendir(DIR, ".");
-        my @flist = readdir(DIR);
-        # Delete any existing symbolic links
-        foreach (grep {/^[\da-f]+\.r{0,1}\d+$/} @flist) {
-                if(-l $_) {
-                        unlink $_;
-                }
-        }
-        closedir DIR;
-        FILE: foreach $fname (grep {/\.pem$/} @flist) {
-                # Check to see if certificates and/or CRLs present.
-                my ($cert, $crl) = check_file($fname);
-                if(!$cert && !$crl) {
-                        print STDERR "WARNING: $fname does not contain a certificate or CRL: skipping\n";
-                        next;
-                }
-                link_hash_cert($fname) if($cert);
-                link_hash_crl($fname) if($crl);
-        }
-}
-
-sub check_file {
-        my ($is_cert, $is_crl) = (0,0);
-        my $fname = $_[0];
-        open IN, $fname;
-        while(<IN>) {
-                if(/^-----BEGIN (.*)-----/) {
-                        my $hdr = $1;
-                        if($hdr =~ /^(X509 |TRUSTED |)CERTIFICATE$/) {
-                                $is_cert = 1;
-                                last if($is_crl);
-                        } elsif($hdr eq "X509 CRL") {
-                                $is_crl = 1;
-                                last if($is_cert);
-                        }
-                }
-        }
-        close IN;
-        return ($is_cert, $is_crl);
-}
-
-
-# Link a certificate to its subject name hash value, each hash is of
-# the form <hash>.<n> where n is an integer. If the hash value already exists
-# then we need to up the value of n, unless its a duplicate in which
-# case we skip the link. We check for duplicates by comparing the
-# certificate fingerprints
-
-sub link_hash_cert {
-                my $fname = $_[0];
-                $fname =~ s/'/'\\''/g;
-                my ($hash, $fprint) = `"$openssl" x509 -hash -fingerprint -noout -in "$fname"`;
-                chomp $hash;
-                chomp $fprint;
-                $fprint =~ s/^.*=//;
-                $fprint =~ tr/://d;
-                my $suffix = 0;
-                # Search for an unused hash filename
-                while(exists $hashlist{"$hash.$suffix"}) {
-                        # Hash matches: if fingerprint matches its a duplicate cert
-                        if($hashlist{"$hash.$suffix"} eq $fprint) {
-                                print STDERR "WARNING: Skipping duplicate certificate $fname\n";
-                                return;
-                        }
-                        $suffix++;
-                }
-                $hash .= ".$suffix";
-                print "$fname => $hash\n";
-                $symlink_exists=eval {symlink("",""); 1};
-                if ($symlink_exists) {
-                        symlink $fname, $hash;
-                } else {
-                        open IN,"<$fname" or die "can't open $fname for read";
-                        open OUT,">$hash" or die "can't open $hash for write";
-                        print OUT <IN>; # does the job for small text files
-                        close OUT;
-                        close IN;
-                }
-                $hashlist{$hash} = $fprint;
-}
-
-# Same as above except for a CRL. CRL links are of the form <hash>.r<n>
-
-sub link_hash_crl {
-                my $fname = $_[0];
-                $fname =~ s/'/'\\''/g;
-                my ($hash, $fprint) = `"$openssl" crl -hash -fingerprint -noout -in '$fname'`;
-                chomp $hash;
-                chomp $fprint;
-                $fprint =~ s/^.*=//;
-                $fprint =~ tr/://d;
-                my $suffix = 0;
-                # Search for an unused hash filename
-                while(exists $hashlist{"$hash.r$suffix"}) {
-                        # Hash matches: if fingerprint matches its a duplicate cert
-                        if($hashlist{"$hash.r$suffix"} eq $fprint) {
-                                print STDERR "WARNING: Skipping duplicate CRL $fname\n";
-                                return;
-                        }
-                        $suffix++;
-                }
-                $hash .= ".r$suffix";
-                print "$fname => $hash\n";
-                $symlink_exists=eval {symlink("",""); 1};
-                if ($symlink_exists) {
-                        symlink $fname, $hash;
-                } else {
-                        system ("cp", $fname, $hash);
-                }
-                $hashlist{$hash} = $fprint;
-}
-