+++ /dev/null
-<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
+++ /dev/null
-<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
+++ /dev/null
-<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
+++ /dev/null
-
- 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/
-
+++ /dev/null
-
-=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
+++ /dev/null
-=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
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>
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
+++ /dev/null
-; 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 . +)
- ))))
-
+++ /dev/null
- 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>
-
+++ /dev/null
-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].
+++ /dev/null
-
-<!-- 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>
-
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
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
+++ /dev/null
-#!/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
+++ /dev/null
-#!/bin/sh
-# print out the hash values
-#
-
-for i in $*
-do
- h=`openssl x509 -hash -noout -in $i`
- echo "$h.0 => $i"
-done
+++ /dev/null
-#!/bin/sh
-#
-# print the subject
-#
-
-for i in $*
-do
- n=`openssl x509 -subject -issuer -enddate -noout -in $i`
- echo "$i"
- echo "$n"
- echo "--------"
-done
+++ /dev/null
-#!/bin/sh
-#
-# print out the issuer
-#
-
-for i in $*
-do
- n=`openssl x509 -issuer -noout -in $i`
- echo "$i $n"
-done
+++ /dev/null
-#!/bin/sh
-#
-# print the subject
-#
-
-for i in $*
-do
- n=`openssl x509 -subject -noout -in $i`
- echo "$i $n"
-done
+++ /dev/null
-#!/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;
-}
-
projects / openbsd / commitdiff
