Bug 856637 - nss-db-gen, change default validity from 12 months to 48 months
nss-db-gen, change default validity from 12 months to 48 months
Status: CLOSED ERRATA
Product: Red Hat Update Infrastructure for Cloud Providers
Classification: Red Hat
Component: RHUA (Show other bugs)
2.1
Unspecified Unspecified
high Severity high
: ---
: 2.1.1
Assigned To: James Slagle
mkovacik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-12 09:46 EDT by wes hayutin
Modified: 2013-02-27 11:59 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The nss-db-gen script generated certificates that are valid for only 12 months. This bug fix updates the script and changes the default validity from 12 months to 48 months.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-27 11:59:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2012-09-12 09:46:23 EDT
Description of problem:

nss-db-gen, change default validity from 12 months to 48 months


-v valid-months

Set the number of months a new certificate will be valid. The validity period begins at the current system time unless an offset is added or subtracted with the -w option. If this argument is not used, the default validity period is three months. When this argument is used, the default three-month period is automatically added to any value given in the valid-month argument. For example, using this option to set a value of 3 would cause 3 to be added to the three-month default, creating a validity period of six months. You can use negative values to reduce the default period. For example, setting a value of -2 would subtract 2 from the default and create a validity period of one month.

-w offset-months

Set an offset from the current system time, in months, for the beginning of a certificate's validity period. Use when creating the certificate or adding it to a database. Express the offset in integers, using a minus sign (-) to indicate a negative offset. If this argument is not used, the validity period begins at the current system time. The length of the validity period is set with the -v argument.

/usr/bin/nss-db-gen

DIR="/tmp/tmp$RANDOM"
HOST=`hostname`
PWDFILE="password"
SEEDFILE="seed"
INST_DIR='/tmp/rhua/qpid'
DB_PASSWORD=""
VALID="12"


change VALID="12" to VALID="48"

also add -w option for an accurate 48 months
Comment 1 James Slagle 2012-11-28 16:41:30 EST
Set the VALID option to 45, since 3 months are added by default, we will get valid certs for 48 months.  AIUI, the -w option is not needed.

commit 34813d3f0a1ba2c5c490888a19b11a76e3f4c649
Comment 3 James Slagle 2012-11-28 16:50:53 EST
QA: Verify the certificates for qpid generated by nss-db-gen are good for 48 months by running the following after installing the rh-rhua-config generated rpm:

certutil -L -d /etc/pki/rhua/qpid-nss/ -n ca
certutil -L -d /etc/pki/rhua/qpid-nss/ -n broker

The displayed certificates should be valid for 48 months.
Comment 4 Vitaly Kuznetsov 2013-02-04 04:50:35 EST
[root@rhua ~]# rpm -q rh-rhui-tools
rh-rhui-tools-2.1.15-1.el6_3.noarch

[root@rhua ~]# certutil -L -d /etc/pki/rhua/qpid-nss/ -n ca | grep "Not "
            Not Before: Mon Feb 04 09:11:50 2013
            Not After : Fri Nov 04 09:11:50 2016
[root@rhua ~]# certutil -L -d /etc/pki/rhua/qpid-nss/ -n broker | grep "Not "
            Not Before: Mon Feb 04 09:11:50 2013
            Not After : Fri Nov 04 09:11:50 2016
Comment 5 Vitaly Kuznetsov 2013-02-19 06:24:34 EST
Certificates are not getting updated with rhui update, they're still valid for 12 month only. 

[root@rhua ~]# certutil -L -d /etc/pki/rhua/qpid-nss/ -n ca | grep "Not "
            Not Before: Mon Feb 18 13:43:45 2013
            Not After : Tue Feb 18 13:43:45 2014
[root@rhua ~]# certutil -L -d /etc/pki/rhua/qpid-nss/ -n broker | grep "Not "
            Not Before: Mon Feb 18 13:43:45 2013
            Not After : Tue Feb 18 13:43:45 2014

I think it was supposed to be this way and we won't go with regenerating them during upgrade. Putting needinfo to be 100% sure.
Comment 6 James Slagle 2013-02-19 12:50:27 EST
that's correct, they won't get updated automatically on a rhui update.  It's a separate manual process.
Comment 8 errata-xmlrpc 2013-02-27 11:59:36 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0571.html

Note You need to log in before you can comment on or make changes to this bug.