RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 624143 - RFE: there is no way to pass in a key or database password on start-tracking
Summary: RFE: there is no way to pass in a key or database password on start-tracking
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Jenny Severance
URL:
Whiteboard:
Depends On: 621670
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-13 19:35 UTC by Nalin Dahyabhai
Modified: 2014-07-25 13:01 UTC (History)
6 users (show)

Fixed In Version: certmonger-0.25-1
Doc Type: Enhancement
Doc Text:
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.
Clone Of: 621670
Environment:
Last Closed: 2011-05-19 13:07:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0570 0 normal SHIPPED_LIVE certmonger bug fix and enhancement update 2011-05-19 09:37:40 UTC

Description Nalin Dahyabhai 2010-08-13 19:35:40 UTC 
+++ This bug was initially created as a clone of Bug #621670 +++

Description of problem:

In IPA I have an couple of server certificates crut ated in the install process that I want certmonger to track. I can get them tracked with ipa-getcert start-tracking but when renewal time rolls around it fails because certmonger doesn't have the NSS database password so can't get at the private keys.

I need to be able to pass in either a password or a file that contains the password (or both)

Version-Release number of selected component (if applicable):

certmonger-0.23-1.fc12.x86_64

--- Additional comment from nalin on 2010-08-05 15:16:38 EDT ---

Under the covers, 'getcert start-tracking' makes the same request that 'getcert request' does, so this is mainly about wiring it into 'getcert start-tracking'. Targeting 0.25 for the fix.

--- Additional comment from nalin on 2010-08-10 17:31:16 EDT ---

Rob, can you spot-check that this works as you'd expect with the development snapshots?  Anything from 6 August on should have the changes I think you need.  If it's good, I'll go ahead and release an 0.25.

--- Additional comment from rcritten on 2010-08-11 09:52:06 EDT ---

With new bits the certificates are now in the state: NEWLY_ADDED_NEED_KEYI_READ_PIN

But I'm still stuck with : how do I provide the pin? Or really, how do I provide a pin or password file when I start the tracking?

--- Additional comment from nalin on 2010-08-11 11:10:13 EDT ---

(In reply to comment #3)
> With new bits the certificates are now in the state:
> NEWLY_ADDED_NEED_KEYI_READ_PIN

Ah, good.  That's where it was supposed to land.  Having it get stuck in NEED_CSR was a symptom of a bug in the code that was supposed to detect failed attempts at logging in to an NSS database.

> But I'm still stuck with : how do I provide the pin? Or really, how do I
> provide a pin or password file when I start the tracking?    

The getcert start-tracking command should recognize -p or -P now, so that the PIN can be passed in either as the name of a file which is consulted when the PIN is needed, or directly (though I tend to agree with you that using a file is better).

--- Additional comment from rcritten on 2010-08-13 09:48:09 EDT ---

Initial tests with -p are looking good. The man page(s) need to be updated as well.

--- Additional comment from updates on 2010-08-13 15:28:49 EDT ---

certmonger-0.26-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/certmonger-0.26-1.fc13

--- Additional comment from updates on 2010-08-13 15:28:59 EDT ---

certmonger-0.26-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/certmonger-0.26-1.fc12

--- Additional comment from updates on 2010-08-13 15:29:08 EDT ---

certmonger-0.26-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/certmonger-0.26-1.fc14
Comment 2 Kaleem 2011-03-14 11:33:15 UTC 
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.
Comment 3 Kaleem 2011-03-17 13:56:09 UTC 
As above in comment #2, Scenario #2 confirms that bug has been fixed.So,turning the status to verified.
Comment 4 Eva Kopalova 2011-05-02 17:06:04 UTC 
    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.
Comment 5 errata-xmlrpc 2011-05-19 13:07:11 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.