Bug 624143 - RFE: there is no way to pass in a key or database password on start-tracking
RFE: there is no way to pass in a key or database password on start-tracking
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Jenny Galipeau
: FutureFeature
Depends On: 621670
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-13 15:35 EDT by Nalin Dahyabhai
Modified: 2014-07-25 09:01 EDT (History)
6 users (show)

See Also:
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.
Story Points: ---
Clone Of: 621670
Environment:
Last Closed: 2011-05-19 09:07:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0570 normal SHIPPED_LIVE certmonger bug fix and enhancement update 2011-05-19 05:37:40 EDT

  None (edit)
Description Nalin Dahyabhai 2010-08-13 15:35:40 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@fedoraproject.org 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@fedoraproject.org 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@fedoraproject.org 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 07:33:15 EDT
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 09:56:09 EDT
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 13:06:04 EDT
    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 09:07:11 EDT
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.