| Message ID | 1529044513-19249-1-git-send-email-erik.kapfer@ipfire.org |
|---|---|
| State | Accepted |
| Commit | 425465ede9a9206efb00aabd954373d780710366 |
| Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (unknown [172.28.1.200]) by web02.i.ipfire.org (Postfix) with ESMTP id B4F28607E0 for <patchwork@web02.i.ipfire.org>; Fri, 15 Jun 2018 08:35:29 +0200 (CEST) Received: from mail01.i.ipfire.org (localhost [127.0.0.1]) by mail01.ipfire.org (Postfix) with ESMTP id C193B108B8A3; Fri, 15 Jun 2018 07:35:28 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=201801; t=1529044529; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references:list-id: list-unsubscribe:list-subscribe:list-post; bh=2nUhh9iKRDl3OjB4DFzyWINQug/O3efmjCDJrZx/X7c=; b=xH5ohjGQVFAy0XQv+ZWwGnF6zQfADxbBnCfP8QmB3npkwjLwLuWVvP+HVDPYqaSdhbsBKE 0VPGE6l2RPhdI2ABIqksqlM4p6OFzCHfgUJwIODwdQwil2Yu+2ihLc7U2gvDMob02u6lDY tVwvK/Ob4oQWkZl2JFIw6czAUy2jGl0xfGw80m0n/MXcCnU6sKbwTABSVoLgEgv+EspCCR k4Un5rKKNjU5fGQEiBpmzaFHkQcEAXMNuP/0iVLWNWzkzGmoTaWxWVWJwU+kQ5E8kGLTHY 6XPGavXxNY4xX1pIylAqOfq7F4FIzuD+LPO3ufR3JBORWgqdJ7Ux7uUup9Wb0w== Received: from localhost.localdomain (i59F4A2E1.versanet.de [89.244.162.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPSA id 59CDE1091020; Fri, 15 Jun 2018 07:35:26 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=201801; t=1529044526; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=2nUhh9iKRDl3OjB4DFzyWINQug/O3efmjCDJrZx/X7c=; b=olUF2NpSI6KgCg05PeexfjLVA0Sbq/mABNzJasDaFHi+bker12X5vqNxv9NQCotpfbfWn7 7mne5/ZOpgYqeCnLuavDGQVitbRB8dRs2wgZn9jLBKy18cYjbnm5VSYQTlXwx7QkU3wdVg 1ops2BRarzh1qsdiWOg2rUcXIdRHLw1xn+igsn4WWvFvZ0ds5erHk+nhABg/65etMvDUVR Zbv7MJStqZvuBSMjT+fPlcE8T1zlqS+rCpEt4IZ04vEvR2DL9LS9BmRIIlgn6wJPMIlX/Q WdzuEo8VXCDBSnXJ8WuheJKDqshbLpLCTFH9XLAeXMpz6sB4D3UqxmxhO8ApAw== From: Erik Kapfer <erik.kapfer@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] OpenVPN: Valid til days is required with OpenVPN-2.4.x Date: Fri, 15 Jun 2018 08:35:13 +0200 Message-Id: <1529044513-19249-1-git-send-email-erik.kapfer@ipfire.org> X-Mailer: git-send-email 2.7.4 Authentication-Results: mail01.ipfire.org; auth=pass smtp.auth=ummeegge smtp.mailfrom=erik.kapfer@ipfire.org X-Spamd-Result: default: False [-2.10 / 11.00]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:8881, ipnet:89.244.160.0/20, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_CONTAINS_FROM(1.00)[]; DKIM_SIGNED(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; BAYES_HAM(-3.00)[100.00%]; RCVD_TLS_ALL(0.00)[] X-Spam-Status: No, score=-2.10 X-Rspamd-Server: mail01.i.ipfire.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <https://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
| Series |
OpenVPN: Valid til days is required with OpenVPN-2.4.x
|
|
Commit Message
Erik Kapfer
June 15, 2018, 4:35 p.m. UTC
Check has been integrated that the OpenSSL maximum of '999999' valid days can not be exceeded.
Check for needed entry in 'Valid til days' field has been integrated.
Asterisk for 'Valid til days' field has been set to mark it as required field.
Signed-off-by: Erik Kapfer <erik.kapfer@ipfire.org>
---
html/cgi-bin/ovpnmain.cgi | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
Comments
Have seen it too late to announce it in the commit message but this patch solves also Bug #11715 Best, Erik
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
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
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@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 <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><a href="https://bugzilla.ipfire.org/show_bug.cgi?id=11742">https://bugzilla.ipfire.org/show_bug.cgi?id=11742</a></div><div><br></div><div>My $0.02,</div><div><br></div><div>Tom</div><div><br>On Jun 18, 2018, at 3:56 AM, ummeegge <<a href="mailto:ummeegge@ipfire.org">ummeegge@ipfire.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hi Michael,</span><br><span>yes but the needs in there can differs a lot so the question arises</span><br><span>what is a good default ?</span><br><span>Another idea might be to add another (or a range of possible days) text</span><br><span>for that field ?</span><br><span>May the error message if an entry triggers one can also be extended.</span><br><span></span><br><span>Greetings,</span><br><span></span><br><span>Erik</span><br><span></span><br><span>Am Sonntag, den 17.06.2018, 19:14 +0100 schrieb Michael Tremer:</span><br><blockquote type="cite"><span>Hello,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>can we also set a good default value for this?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This can be a little bit confusing for new users and it would be good</span><br></blockquote><blockquote type="cite"><span>to have</span><br></blockquote><blockquote type="cite"><span>some guidance. It can be a separate patch.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Best,</span><br></blockquote><blockquote type="cite"><span>-Michael</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Fri, 2018-06-15 at 14:59 +0200, ummeegge wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Have seen it too late to announce it in the commit message but this</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>patch solves also Bug #11715</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Best,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Erik</span><br></blockquote></blockquote></div></blockquote></body></html>
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/openvpn/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/recommendations-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@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
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/openv > > 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@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 > >
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@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
Hi Michael, yes i think 730 days are a good default. Patch is already made. Can you merge the already delivered one so i can pull the actual state and make then an own patch for this ? Best, Erik Am Montag, den 18.06.2018, 14:51 +0100 schrieb Michael Tremer: > 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 >
Yes, can do. Please see "next". In the future, you can create an own OpenVPN branch where all those proposed patches are collected to be able to work a little bit independent from me and also to collect patches and submit them in one go. Best, -Michael On Mon, 2018-06-18 at 16:05 +0200, ummeegge wrote: > Hi Michael, > yes i think 730 days are a good default. Patch is already made. > Can you merge the already delivered one so i can pull the actual state > and make then an own patch for this ? > > Best, > > Erik > > Am Montag, den 18.06.2018, 14:51 +0100 schrieb Michael Tremer: > > 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 > > > >
OK, will do that. Thanks. Best, Erik Am Montag, den 18.06.2018, 15:08 +0100 schrieb Michael Tremer: > Yes, can do. Please see "next". > > In the future, you can create an own OpenVPN branch where all those > proposed > patches are collected to be able to work a little bit independent > from me and > also to collect patches and submit them in one go. > > Best, > -Michael >
diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index eac962e..99d39a9 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -3980,6 +3980,16 @@ if ($cgiparams{'TYPE'} eq 'net') { goto VPNCONF_ERROR; } + # Check for N2N that OpenSSL maximum of valid days will not be exceeded + if ($cgiparams{'TYPE'} eq 'net') { + if ($cgiparams{'DAYS_VALID'} >= '999999') { + $errormessage = $Lang::tr{'invalid input for valid till days'}; + unlink ("${General::swroot}/ovpn/n2nconf/$cgiparams{'NAME'}/$cgiparams{'NAME'}.conf") or die "Removing Configfile fail: $!"; + rmdir ("${General::swroot}/ovpn/n2nconf/$cgiparams{'NAME'}") || die "Removing Directory fail: $!"; + goto VPNCONF_ERROR; + } + } + if ($cgiparams{'ENABLED'} !~ /^(on|off)$/) { $errormessage = $Lang::tr{'invalid input'}; goto VPNCONF_ERROR; @@ -4157,11 +4167,19 @@ if ($cgiparams{'TYPE'} eq 'net') { $errormessage = $Lang::tr{'passwords do not match'}; goto VPNCONF_ERROR; } - if ($cgiparams{'DAYS_VALID'} ne '' && $cgiparams{'DAYS_VALID'} !~ /^[0-9]+$/) { + if ($cgiparams{'DAYS_VALID'} eq '' && $cgiparams{'DAYS_VALID'} !~ /^[0-9]+$/) { $errormessage = $Lang::tr{'invalid input for valid till days'}; goto VPNCONF_ERROR; } + # Check for RW that OpenSSL maximum of valid days will not be exceeded + if ($cgiparams{'TYPE'} eq 'host') { + if ($cgiparams{'DAYS_VALID'} >= '999999') { + $errormessage = $Lang::tr{'invalid input for valid till days'}; + goto VPNCONF_ERROR; + } + } + # Replace empty strings with a . (my $ou = $cgiparams{'CERT_OU'}) =~ s/^\s*$/\./; (my $city = $cgiparams{'CERT_CITY'}) =~ s/^\s*$/\./; @@ -4813,7 +4831,7 @@ END if ($cgiparams{'TYPE'} eq 'host') { print <<END; </select></td></tr> - <td> </td><td class='base'>$Lang::tr{'valid till'} (days):</td> + <td> </td><td class='base'>$Lang::tr{'valid till'} (days): <img src='/blob.gif' alt='*' /</td> <td class='base' nowrap='nowrap'><input type='text' name='DAYS_VALID' value='$cgiparams{'DAYS_VALID'}' size='32' $cakeydisabled /></td></tr> <tr><td> </td> <td class='base'>$Lang::tr{'pkcs12 file password'}:</td> @@ -4828,7 +4846,7 @@ END }else{ print <<END; </select></td></tr> - <td> </td><td class='base'>$Lang::tr{'valid till'} (days):</td> + <td> </td><td class='base'>$Lang::tr{'valid till'} (days): <img src='/blob.gif' alt='*' /</td> <td class='base' nowrap='nowrap'><input type='text' name='DAYS_VALID' value='$cgiparams{'DAYS_VALID'}' size='32' $cakeydisabled /></td></tr> <tr><td> </td><td> </td><td> </td></tr> <tr><td> </td><td> </td><td> </td></tr>