diff --git a/doc/ca-renew-cert.pod b/doc/ca-renew-cert.pod
new file mode 100644
index 0000000..fb8947a
--- /dev/null
+++ b/doc/ca-renew-cert.pod
@@ -0,0 +1,94 @@
+#! /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> -t I<type> [B<-f> I<config>] [B<-d> I<days>]
+I<hostname, username, or 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 is mandatory and tells 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