95 lines
3 KiB
Bash
Executable file
95 lines
3 KiB
Bash
Executable file
#! /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
|