ikectl ca's 1 year validity

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

ikectl ca's 1 year validity

Stuart Henderson
I usually setup iked with certificates generated by other tooling, but
have used "ikectl ca" once or twice when I've been in a hurry, and each
time have been bitten by the default validities. It uses 365 days for

For server certificates it's simple enough to rekey or at least re-sign
so 1 year default seems reasonable. In addition this is controlled by
an easily editable .cnf file.

Client certificates are a bit more hassle to update but like server
certificates you don't usually want hugely long validity for these.
Again they're controlled by the .cnf file, and the most common end-
user-facing setups using EAP username/password login don't need them

For CRLs and CA certificates this is hardcoded in the ikectl binary.
A year is *way* too short for root CA validity. Can we bump it? The
proposal below feels reasonable to me for ikectl but I'm open to other
suggestions (I'm fairly happy with this being hardcoded for ikectl ca
use, as long as it's a sane value .. users with strong opinions or
policies diverging from ikectl's default are likely to know enough
to be able to manage their CA with other tools).

Index: ikeca.c
RCS file: /cvs/src/usr.sbin/ikectl/ikeca.c,v
retrieving revision 1.47
diff -u -p -r1.47 ikeca.c
--- ikeca.c 8 Nov 2017 09:33:37 -0000 1.47
+++ ikeca.c 14 Feb 2019 20:44:31 -0000
@@ -429,7 +429,7 @@ ca_create(struct ca *ca)
  chmod(path, 0600);
- snprintf(cmd, sizeof(cmd), "%s x509 -req -days 365"
+ snprintf(cmd, sizeof(cmd), "%s x509 -req -days 4500"
     " -in %s/private/ca.csr -signkey %s/private/ca.key"
     " -sha256"
     " -extfile %s -extensions x509v3_CA -out %s/ca.crt -passin file:%s",