From: afresh1 Date: Sun, 20 Apr 2014 19:23:08 +0000 (+0000) Subject: Remove unused/never installed libssl tools and docs and references to them X-Git-Url: http://artulab.com/gitweb/?a=commitdiff_plain;h=2cd76d8919b12d9263d1a51a1a03c27bb2df7886;p=openbsd Remove unused/never installed libssl tools and docs and references to them Sure deraadt --- diff --git a/lib/libssl/src/doc/HOWTO/certificates.txt b/lib/libssl/src/doc/HOWTO/certificates.txt deleted file mode 100644 index a8a34c7abc5..00000000000 --- a/lib/libssl/src/doc/HOWTO/certificates.txt +++ /dev/null @@ -1,105 +0,0 @@ - - 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 . 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 . 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 -). 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 , 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/lib/libssl/src/doc/HOWTO/keys.txt b/lib/libssl/src/doc/HOWTO/keys.txt deleted file mode 100644 index 7ae2a3a1183..00000000000 --- a/lib/libssl/src/doc/HOWTO/keys.txt +++ /dev/null @@ -1,73 +0,0 @@ - - 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/lib/libssl/src/doc/HOWTO/proxy_certificates.txt b/lib/libssl/src/doc/HOWTO/proxy_certificates.txt deleted file mode 100644 index f98ec360767..00000000000 --- a/lib/libssl/src/doc/HOWTO/proxy_certificates.txt +++ /dev/null @@ -1,322 +0,0 @@ - - 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/lib/libssl/src/doc/README b/lib/libssl/src/doc/README deleted file mode 100644 index 6ecc14d9945..00000000000 --- a/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/lib/libssl/src/doc/apps/CA.pl.pod b/lib/libssl/src/doc/apps/CA.pl.pod deleted file mode 100644 index d326101cde7..00000000000 --- a/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 -[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] - -=head1 DESCRIPTION - -The B script is a perl script that supplies the relevant command line -arguments to the B 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 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 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 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 - -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 creates RSA CAs and requests it is still possible to -use it with DSA certificates and requests using the L 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 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 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 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 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 command directly. - -=head1 ENVIRONMENT VARIABLES - -The variable B 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, L, L, L, -L - -=cut diff --git a/lib/libssl/src/doc/apps/tsget.pod b/lib/libssl/src/doc/apps/tsget.pod deleted file mode 100644 index 56db985c4bb..00000000000 --- a/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 -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 command can be used for sending a time stamp request, as -specified in B, 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 command to -do that. B 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/ - Host: : - Pragma: no-cache - Content-Type: application/timestamp-query - Accept: application/timestamp-reply - Content-Length: length of body - - ...binary request specified by the user... - -B 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 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 - 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 -will ask for it. (Optional) - -=item B<-c> client_cert.pem - -(HTTPS) In case of certificate-based client authentication over HTTPS - 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 -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 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 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 and B 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 -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 , OpenTSA project (http://www.opentsa.org) - -=head1 SEE ALSO - -L, L, L, -B - -=cut diff --git a/lib/libssl/src/doc/apps/verify.pod b/lib/libssl/src/doc/apps/verify.pod index da683004bd2..f1d5384b9a5 100644 --- a/lib/libssl/src/doc/apps/verify.pod +++ b/lib/libssl/src/doc/apps/verify.pod @@ -43,8 +43,7 @@ The B 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 utility). Under Unix the B script will automatically -create symbolic links to a directory of certificates. +of the B utility). =item B<-CAfile file> diff --git a/lib/libssl/src/doc/apps/x509.pod b/lib/libssl/src/doc/apps/x509.pod index d2d9eb812af..314018f0862 100644 --- a/lib/libssl/src/doc/apps/x509.pod +++ b/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 or similar. +the old form must have their links rebuilt. =cut diff --git a/lib/libssl/src/doc/c-indentation.el b/lib/libssl/src/doc/c-indentation.el deleted file mode 100644 index 90861d39797..00000000000 --- a/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 (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/lib/libssl/src/doc/fingerprints.txt b/lib/libssl/src/doc/fingerprints.txt deleted file mode 100644 index 7d05a855946..00000000000 --- a/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 -uid Richard Levitte -uid Richard Levitte - -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 - -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 -uid Mark Cox -uid Mark Cox - -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 - -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 - -pub 1024D/2118CF83 1998-07-13 - Key fingerprint = 7656 55DE 62E3 96FF 2587 EB6C 4F6D E156 2118 CF83 -uid Ben Laurie -uid Ben Laurie -uid Ben Laurie -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 -uid Bodo Moeller -uid Bodo Moeller -uid Bodo Moeller <3moeller@informatik.uni-hamburg.de> -uid Bodo Moeller -uid Bodo Moeller <3moeller@rzdspc5.informatik.uni-hamburg.de> - diff --git a/lib/libssl/src/doc/openssl-shared.txt b/lib/libssl/src/doc/openssl-shared.txt deleted file mode 100644 index 5cf84a054ff..00000000000 --- a/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/lib/libssl/src/doc/openssl_button.gif b/lib/libssl/src/doc/openssl_button.gif deleted file mode 100644 index 3d3c90c9f84..00000000000 Binary files a/lib/libssl/src/doc/openssl_button.gif and /dev/null differ diff --git a/lib/libssl/src/doc/openssl_button.html b/lib/libssl/src/doc/openssl_button.html deleted file mode 100644 index 44c91bd3d06..00000000000 --- a/lib/libssl/src/doc/openssl_button.html +++ /dev/null @@ -1,7 +0,0 @@ - - - - - - diff --git a/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod b/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod index de010652850..cd78dd285fb 100644 --- a/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod +++ b/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 utility to create the necessary links. The certificates in B 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: 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/lib/libssl/src/tools/c89.sh b/lib/libssl/src/tools/c89.sh deleted file mode 100644 index b25c9fda2df..00000000000 --- a/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/lib/libssl/src/tools/c_hash b/lib/libssl/src/tools/c_hash deleted file mode 100644 index 5e0a9081755..00000000000 --- a/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/lib/libssl/src/tools/c_info b/lib/libssl/src/tools/c_info deleted file mode 100644 index 0e1e633b6fb..00000000000 --- a/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/lib/libssl/src/tools/c_issuer b/lib/libssl/src/tools/c_issuer deleted file mode 100644 index 55821ab740d..00000000000 --- a/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/lib/libssl/src/tools/c_name b/lib/libssl/src/tools/c_name deleted file mode 100644 index 28800c0b30c..00000000000 --- a/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/lib/libssl/src/tools/c_rehash.in b/lib/libssl/src/tools/c_rehash.in deleted file mode 100644 index bfc4a69ed4b..00000000000 --- a/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() { - 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 . 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 ; # 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 .r - -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; -} -