#! /bin/sh

if [ -z "$1" -o "$1" == "man" ]; then
  exec /usr/bin/pod2man -n CA-RENEW-CERT -s 1 -d "12 February 2010" \
    -r "ca-scripts version 0.9" -c "SSL Certificate Authority utilities" $0
elif [ "$1" == "html" ]; then
  exec /usr/bin/pod2html --title "ca-renew-cert(1)" < $0
elif [ "$1" == "text" ]; then
  exec /usr/bin/pod2text -o $0
fi
echo "Unrecognised output format '$1', try man, html, or text."
exit 1

=pod

=head1 NAME

ca-renew-cert - renew a previously generated X.509 certificate

=head1 SYNOPSIS

B<ca-renew-cert> [B<-f> I<config>] [B<-t> I<type>] [B<-d> I<days>]
I<common name>|<path to certificate>

B<ca-renew-cert> [B<-h>] | [B<--help>]

=head1 DESCRIPTION

B<ca-renew-cert> renews certificates generated with ca-create-cert(1),
extending their validity for a configurable number of days, defaulting to
B<CA_CRT_DAYS>.

=head1 OPTIONS

B<ca-renew-cert> can infer the correct cached configurations to use for
certificate renewal from the hostname of a I<server> or I<client>, the
username of a I<user>, or the path to a previously generated certificate of any
type.

=over

=item B<-t> I<TYPE>, B<--type> I<TYPE>

This argument overrides the type detection if multiple certificate types share
the same common name, telling B<ca-renew-cert> what type of certificate it is
renewing, either I<server>, I<client>, or I<user>.

=item B<-f> I<FILE>, B<--config> I<FILE>

Load the ca-scripts configuration from I<FILE> instead of
I</etc/ca-scripts.conf>.

=item B<-d> I<DAYS>, B<--days> I<DAYS>

Renew the certificate to be valid for I<DAYS> days instead of the default
B<CA_CRT_DAYS> set in the configuration file.

=back

=head1 BUGS

B<ca-renew-cert> is currently very careful to re-use the original key and
certificate serial when it renews a certificate. This is not strictly necessary
for most renewals, and may in fact reduce the long-term security of your SSL
certificates.

The usual renewal process is to re-generate a new CSR and private
key with the same DN and sign it as valid for the required time period.
This has the unfortunate side-effect of rendering unreadable all S/MIME e-mail
and data encrypted with the previous certificate and private key. It will also
invalidate any old digital signatures created with the previous certificate.
Instead, B<ca-renew-cert> re-signs the old CSR with the same serial and a new
validity period, which ensures that no data is lost.

Arguably, it would be better to support both modes of renewal, and re-generate
a new CSR and key for I<server> and I<client> certificates while re-signing old
CSRs for I<user> certificates. This may be implemented in future releases.

=head1 AVAILABILITY

New releases of the ca-scripts utilities can be found at
L<the developer's website|http://www.pl0rt.org/code/ca-scripts>.
A L<git repository|git://git.pl0rt.org/alex/code/ca-scripts>
for development versions also exists.

=head1 AUTHORS

Copyright 2009, 2010 Alex Bramley a.bramley@gmail.com

=head1 SEE ALSO

ca-create-cert(1), ca-scripts.conf(5), openssl(1ssl), ca(1ssl), req(1ssl),
x509(1ssl), config(5ssl), and x509v3_config(5ssl).

=cut