Bug 624143

Few observations about various following scenarios.
Please let me know your comment on the following scenarios.

Scenario 1: When the NSS database password is default(blank) or customized with -p or -P switch and password has been not changed before certificate expiry

  In the above scenario, certificates gets tracked by certmonger and also re-issued when close to expiry date successfully.

Scenario 2: When the NSS database password is default(blank) or customized with -p or -P switch and password has been changed before certificate expiry

  In this scenario, certificates gets tracked by certmonger but its status gets changed to
  'NEED_CSR_GEN_PIN' when expiry date is close.

 [root@jupiter kaleem]# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110310122724':
    status: NEED_CSR_GEN_PIN
    stuck: yes
    key pair storage: type=NSSDB,location='/tmp/kaleem',nickname=test,pinfile=/tmp/kaleem/password
    certificate: type=NSSDB,location='/tmp/kaleem',nickname=test,token='NSS Certificate DB'
    CA: IPA
    issuer: CN=Certificate Authority,O=LAB.ENG.PNQ.REDHAT.COM
    subject: CN=jupiter.lab.eng.pnq.redhat.com,O=LAB.ENG.PNQ.REDHAT.COM
    expires: 20110906122726
    eku: id-kp-serverAuth
    track: yes
    auto-renew: yes

  Now when we tried to pass the right password using start-tracking argument, certmonger re-issues the certificate.

     root@jupiter kaleem]# ipa-getcert start-tracking -i 20110310122724 -p /tmp/kaleem/test
Request "20110310122724" modified.
[root@jupiter kaleem]# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110310122724':
    status: MONITORING
    stuck: no
    key pair storage: type=NSSDB,location='/tmp/kaleem',nickname=test,token='NSS Certificate DB',pin=temp123#,pinfile=/tmp/kaleem/test
    certificate: type=NSSDB,location='/tmp/kaleem',nickname=test,token='NSS Certificate DB'
    CA: IPA
    issuer: CN=Certificate Authority,O=LAB.ENG.PNQ.REDHAT.COM
    subject: CN=jupiter.lab.eng.pnq.redhat.com,O=LAB.ENG.PNQ.REDHAT.COM
    expires: 20120301122025
    eku: id-kp-serverAuth
    track: yes
    auto-renew: yes

Scenario 3: when NSS database password is 8 character string and invalid password file is provided along with certmonger debug level set to 1

(a)Creating the NSS database with password(temp123#)

[root@jupiter test]# certutil -N -d /tmp/kaleem/test/
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password: 
Re-enter password: 
[root@jupiter test]# 

(b)Generating the certificate

[root@jupiter test]# ipa-getcert request -d /tmp/kaleem/test/ -n test -r -p /tmp/kaleem/test/passwordfile
New signing request "20110314104811" added.
[root@jupiter test]#

(c)Certmonger's debug output

[root@jupiter ~]# certmonger -S -d 1
2011-03-14 16:18:11 [4509] Error reading PIN from "/tmp/kaleem/test/passwordfile": No such file or directory.
2011-03-14 16:18:11 [4509] Error authenticating to token "NSS Certificate DB".
2011-03-14 16:18:11 [4509] Error locating key.
2011-03-14 16:18:11 [4510] Error reading PIN from "/tmp/kaleem/test/passwordfile": No such file or directory.
2011-03-14 16:18:11 [4510] Key storage slot still needs user PIN to be set.
2011-03-14 16:18:11 [4510] Error locating certificate.
2011-03-14 16:18:11 [4511] Error reading PIN from "/tmp/kaleem/test/passwordfile": No such file or directory.
2011-03-14 16:18:11 [4511] Error authenticating to token "NSS Certificate DB".
2011-03-14 16:18:11 [4511] Error locating key.

(d)Output of 'ipa-getcert list' command

[root@jupiter requests]# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110314104811':
	status: NEWLY_ADDED_NEED_KEYI_READ_PIN
	stuck: yes
	key pair storage: type=NSSDB,location='/tmp/kaleem/test',nickname=test,pinfile=/tmp/kaleem/test/passwordfile
	certificate: type=NSSDB,location='/tmp/kaleem/test',nickname=test
	CA: IPA
	issuer: 
	subject: 
	expires: unknown
	track: yes
	auto-renew: yes

In the above scenario certificate is not generated.

Scenario 4: when NSS database password is null and an invalid password file is provided along with certmonger debug level set to 1

(a)Creating the NSS database with null password

[root@jupiter test1]# certutil -N -d /tmp/kaleem/test1/
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password: 
Re-enter password: 
[root@jupiter test1]#

(b)Generating the certificate

[root@jupiter test1]# ipa-getcert request -d /tmp/kaleem/test1/ -n test1 -r -p /tmp/kaleem/test1/passwordfile
New signing request "20110314105455" added.
[root@jupiter test1]#

(c)Certmonger's debug output

[root@jupiter ~]# certmonger -S -d 1
2011-03-14 16:24:55 [4530] Error locating key.
2011-03-14 16:24:55 [4531] Error reading PIN from "/tmp/kaleem/test1/passwordfile": No such file or directory.
2011-03-14 16:24:55 [4531] Key storage slot still needs user PIN to be set.
2011-03-14 16:24:55 [4531] Error locating certificate.
2011-03-14 16:24:55 [4532] Error locating key.
2011-03-14 16:24:55 [4533] Error reading PIN from "/tmp/kaleem/test1/passwordfile": No such file or directory.
2011-03-14 16:24:55 [4533] Key storage slot still needs user PIN to be set.
2011-03-14 16:24:55 [4533] Error locating certificate.
2011-03-14 16:24:57 [4520] Certificate submission still ongoing.
2011-03-14 16:24:57 [4520] Certificate submission attempt complete.
2011-03-14 16:24:57 [4520] Child status = 0.
2011-03-14 16:24:57 [4520] Child output:
-----BEGIN CERTIFICATE-----
MIIDoDCCAoigAwIBAgIBNjANBgkqhkiG9w0BAQsFADBBMR8wHQYDVQQKExZMQUIu
RU5HLlBOUS5SRURIQVQuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3Jp
dHkwHhcNMTEwMzE0MTA1NDU3WhcNMTEwOTEwMTA1NDU3WjBKMR8wHQYDVQQKExZM
QUIuRU5HLlBOUS5SRURIQVQuQ09NMScwJQYDVQQDEx5qdXBpdGVyLmxhYi5lbmcu
cG5xLnJlZGhhdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8
7LPa0gRhJIMjoFcNr7BUpjeD808u2cPpWf2qmTJY/LXlvGU19ZWTIBBh/wuxMLcl
YlDlzF6Ufr503mthNlrlQM1sJakaBEagjsLMbLTQiOuUrD/AP8sQREfdqgHkWw5i
/7qOo41W26GDJvRLMY3VgZy5vW1044nqqfxPIuUHMv1awIFHGI0A3KjXatfy9sJf
L9Q9jE3Ji4Tnyjabz5Foe32W6RgB0RQze43WmNkYtwYwpcOZXlEHfHQH8W0+7A2w
CEnW7QbsTM6BDDFtUN6iCy6/eU4AYExh6ySJ7o3bLHLbn9icQQWe4hFrJjISSNXX
8WHytLGK/y66UsGIAimdAgMBAAGjgZkwgZYwHwYDVR0jBBgwFoAUBOXf0/5ulZ76
LxJZOq5cmFSFHe0wTgYIKwYBBQUHAQEEQjBAMD4GCCsGAQUFBzABhjJodHRwOi8v
anVwaXRlci5sYWIuZW5nLnBucS5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNV
HQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQAD
ggEBAH44PumU8ZXKVhzZAHnsYIygigSEjsYrXjVcIcXtQThTgT1jI0zZpsIQ51W2
0wr4by2WVO1VmCjAzkChnnX+BuUR1IhUOQZ/FU3N3oQLddC0rkvSC7fmBDsa6dsh
0cxqxHK/v62XFuTh5DHNVHYvLMhEbezg9Z33DQ4JtOp0sLRze2s4rPSWGWYMI1Ie
eRcYG3T51K3IWlj4yWCq9DFCgOYKK9olNPhY60zo38O1JOvJpdo6GIQiNShLe6U5
ubfCyXyac+k6WkVGQzlLuerxG7TiMrwd9XdzwVjDzm/0hRT+BxIl8wLPNb8NDeOR
X3T9fEYFUVBC5JhDCZUtwDpTi54=
-----END CERTIFICATE-----

2011-03-14 16:24:57 [4520] Certificate issued.
2011-03-14 16:24:57 [4540] Token is named "NSS Generic Crypto Services", not "(null)".


(d)Output of 'ipa-getcert list' command

[root@jupiter requests]# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20110314105455':
	status: MONITORING
	stuck: no
	key pair storage: type=NSSDB,location='/tmp/kaleem/test1',nickname=test1,pinfile=/tmp/kaleem/test1/passwordfile
	certificate: type=NSSDB,location='/tmp/kaleem/test1',nickname=test1,token='NSS Certificate DB'
	CA: IPA
	issuer: CN=Certificate Authority,O=LAB.ENG.PNQ.REDHAT.COM
	subject: CN=jupiter.lab.eng.pnq.redhat.com,O=LAB.ENG.PNQ.REDHAT.COM
	expires: 20110910105457
	eku: id-kp-serverAuth
	track: yes
	auto-renew: yes
[root@jupiter requests]#

In the above scenario certificate is generated.

As above in comment #2, Scenario #2 confirms that bug has been fixed.So,turning the status to verified.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The "ipa-getcert" and "getcert" commands did not accept the location of a passphrase, which could provide the encrypted keying material and allow monitoring of an already-issued certificate or key pair. This update adds the "-p" and "-P" options to the "getcert start-tracking" command, which allows the user to pass the utility a PIN either in a file or directly.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0570.html