From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Valid til days is required with OpenVPN-2.4.x
Date: Mon, 18 Jun 2018 14:51:40 +0100 [thread overview]
Message-ID: <002b508cf560f6802a0d7664e8365c60d5ee566d.camel@ipfire.org> (raw)
In-Reply-To: <f529e572f8df77c2dad7000fb830529cb6b6bf42.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]
I think that a reasonable default would be 2 years.
That is already the maximum I would feel comfortable with, but certificates
*must* expire. They should not run for forever.
But I agree with Tom that there should be an easy way to extend the certificate
and that we should have some UI elements that warn when a certificate is going
to expire in the next ~30 days or so.
@Erik: Would you be up for implementing this?
Best,
-Michael
On Mon, 2018-06-18 at 14:09 +0100, Michael Tremer wrote:
> How relevant is this one here?
>
> https://bugzilla.ipfire.org/show_bug.cgi?id=10482
>
> -Michael
>
> On Mon, 2018-06-18 at 08:21 -0400, Tom Rymes wrote:
> > Erik,
> >
> > Tossing this back on the list, I hope you don't mind.
> >
> > My apologies, I was unclear. What I mean is that the user will *want* a
> > longer lifetime, even though the longest *possible* lifetime will be too
> > long for security reasons.
> >
> > In other words, my suggestion would be to use the longest lifetime
> > consistent with best practices, like those that you include below.
> >
> > Tom
> >
> > On 06/18/2018 8:00 AM, ummeegge wrote:
> > > Hi Tom,
> > > in my opinion this is the wrong suggestion since we circumvent in fact
> > > the new security feature from OpenSSL. The longest lifetime would be
> > > then '999998' days which is adequate to ~2740 years whereby we and our
> > > systems possibly wont go through :D .
> > >
> > > Additionally OpenVPNs hardening wiki --> https://community.openvpn.net/ope
> > > nv
> > > pn/wiki/Hardening#X.509keysize
> > > points a so called "future system near term use" (data are from Enisa) out
> > > whereby 3072 bit RSA key lenghts and more are recommended to stay safe in
> > > Enisa definitions for at least 10 years (research was from 2013) but
> > > IPFire
> > > uses
> > > currently 2048 bit RSA for the host certificate.
> > >
> > > May not representative but Microsoft said in 2009 something like this:
> > >
> > > Key length of 1024: Validity period = not greater than 6-12 monthsKey
> > > length of 2048: Validity period = not greater than 2 yearsKey length of
> > > 4096: Validity period = not greater than 16 years
> > >
> > > <-- is from https://cloudblogs.microsoft.com/enterprisemobility/2009/06/12
> > > /r
> > > ecommendations-for-pki-key-lengths-and-validity-periods-with-
> > > configuration-
> > > manager/
> > >
> > > May there are more actual papers for that...
> > >
> > >
> > > Best,
> > >
> > > Erik
> > >
> > >
> > > Am Montag, den 18.06.2018, 06:27 -0400 schrieb Tom Rymes:
> > > > I’d suggest that most users likely want the longest lifetime for
> > > > their certs that they can get, so as to avoid the need to frequently
> > > > replace expired certificates.
> > > >
> > > > This is especially true because there is no way to recreate certs in
> > > > the WUI when they expire, so you have to delete the entry and
> > > > recreate it when that happens.
> > > >
> > > > https://bugzilla.ipfire.org/show_bug.cgi?id=11742
> > > >
> > > > My $0.02,
> > > >
> > > > Tom
> > > >
> > > > On Jun 18, 2018, at 3:56 AM, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > >
> > > > > Hi Michael,
> > > > > yes but the needs in there can differs a lot so the question arises
> > > > > what is a good default ?
> > > > > Another idea might be to add another (or a range of possible days)
> > > > > text
> > > > > for that field ?
> > > > > May the error message if an entry triggers one can also be
> > > > > extended.
> > > > >
> > > > > Greetings,
> > > > >
> > > > > Erik
> > > > >
> > > > > Am Sonntag, den 17.06.2018, 19:14 +0100 schrieb Michael Tremer:
> > > > > > Hello,
> > > >
> > > > can we also set a good default value for this?
> > > >
> > > >
> > > > This can be a little bit confusing for new users and it would be good
> > > >
> > > > to have
> > > >
> > > > some guidance. It can be a separate patch.
> > > >
> > > >
> > > > Best,
> > > >
> > > > -Michael
> > > >
> > > >
> > > > On Fri, 2018-06-15 at 14:59 +0200, ummeegge wrote:
> > > >
> > > > >
> > > > > Have seen it too late to announce it in the commit message but this
> > > > > patch solves also Bug #11715
> > > > >
> > > > > Best,
> > > > >
> > > > > Erik
next prev parent reply other threads:[~2018-06-18 13:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1529323219.5499.21.camel@ipfire.org>
2018-06-18 12:21 ` Tom Rymes
2018-06-18 13:09 ` Michael Tremer
2018-06-18 13:51 ` Michael Tremer [this message]
2018-06-18 14:05 ` ummeegge
2018-06-18 14:08 ` Michael Tremer
2018-06-18 14:10 ` ummeegge
2018-06-15 6:35 Erik Kapfer
2018-06-15 12:59 ` ummeegge
2018-06-17 18:14 ` Michael Tremer
2018-06-18 7:56 ` ummeegge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=002b508cf560f6802a0d7664e8365c60d5ee566d.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox