Bug 1249753 - challenge password not added in csr using start-tracking
challenge password not added in csr using start-tracking
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: certmonger (Show other bugs)
7.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jan Cholasta
Kaleem
https://git.fedorahosted.org/cgit/cer...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 13:31 EDT by Kaleem
Modified: 2015-11-19 06:59 EST (History)
4 users (show)

See Also:
Fixed In Version: certmonger-0.78.4-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 06:59:11 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)
console output with steps (14.56 KB, text/plain)
2015-08-03 13:31 EDT, Kaleem
no flags Details
console output for csr at renewal time (8.23 KB, text/plain)
2015-08-04 02:35 EDT, Kaleem
no flags Details

  None (edit)
Description Kaleem 2015-08-03 13:31:29 EDT
Created attachment 1058822 [details]
console output with steps

Description of problem:
This i observed while using challenge password option with "getcert start-tracking" option and this causes 

Version-Release number of selected component (if applicable):
[root@cloud-qe-14 ~]# rpm -q certmonger
certmonger-0.78.3-1.el7.x86_64
[root@cloud-qe-14 ~]# 

How reproducible:
Always

Steps to Reproduce:
1. Cert request to local CA
2. Start-tracking to cert generated in step(1) with SCEP-CA by providing challenge password
3. look at the modified csr

Actual results:
Challenge password is missing in csr and this causes request to fail at the time of renewal of cert

Expected results:
Challenge password should exist in csr 

Additional info:
(1)Please find the attached console output of steps performed.
Comment 2 Nalin Dahyabhai 2015-08-03 16:27:01 EDT
What I'm seeing here is the CSR not being regenerated until one needs to be sent to the CA, which is expected, and when it's regenerated, it contains the previously-specified challenge password.

I thought the case we were discussing on IRC was about an automatic renewal somehow leading to a CSR being regenerated without containing the previously-specified challenge password.  Is that happening?
Comment 3 Kaleem 2015-08-04 02:34:20 EDT
(In reply to Nalin Dahyabhai from comment #2)
> What I'm seeing here is the CSR not being regenerated until one needs to be
> sent to the CA, which is expected, and when it's regenerated, it contains
> the previously-specified challenge password.
> 
> I thought the case we were discussing on IRC was about an automatic renewal
> somehow leading to a CSR being regenerated without containing the
> previously-specified challenge password.  Is that happening?

Yes CSR generation at time of automatic renewal do not have the specified challenge password.

Please find the attached console output for same.
Comment 4 Kaleem 2015-08-04 02:35:10 EDT
Created attachment 1058951 [details]
console output for csr at renewal time
Comment 5 Nalin Dahyabhai 2015-08-04 11:00:34 EDT
Yes, I can confirm that getcert start-tracking doesn't pass a new challenge password or challenge password file in when it goes to modify an already-tracked certificate, even though it's supposed to do so.  It should be fixed in master shortly.
Comment 7 Kaleem 2015-09-03 14:05:13 EDT
Verified.

[root@dhcp207-177 ~]# rpm -q certmonger
certmonger-0.78.4-1.el7.x86_64
[root@dhcp207-177 ~]#

Snip from console output:
=========================
[root@yttrium ~]# getcert request -I newtest -k /root/sceptest/newkey.prv -f /root/sceptest/newcert.cer -c local
New signing request "newtest" added.
[root@yttrium ~]# getcert list -i newtest
Number of certificates and requests being tracked: 1.
Request ID 'newtest':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/root/sceptest/newkey.prv'
	certificate: type=FILE,location='/root/sceptest/newcert.cer'
	CA: local
	issuer: CN=94a54cb8-a6944955-a15a8e7a-91a4b32f,CN=Local Signing Authority
	subject: CN=yttrium.idmqe.lab.eng.bos.redhat.com
	expires: 2016-08-10 10:51:52 UTC
	dns: yttrium.idmqe.lab.eng.bos.redhat.com
	eku: id-kp-serverAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
[root@yttrium ~]# getcert start-tracking -i newtest -c scepca -L EA90FEF73AD5DA5A203F590AC1428CCC
Request "newtest" modified.
[root@yttrium ~]# date -s "+364 days"
Mon Aug  8 06:52:30 EDT 2016
[root@yttrium ~]# getcert list -i newtest
Number of certificates and requests being tracked: 1.
Request ID 'newtest':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/root/sceptest/newkey.prv'
	certificate: type=FILE,location='/root/sceptest/newcert.cer'
	signing request thumbprint (MD5): 9631309F F86303FB 1A7E0DDA 072E2E2D
	signing request thumbprint (SHA1): 2DD6B57E 47DA0B07 9A083E41 8F08BC7A C652255D
	CA: scepca
	issuer: CN=sceptest-SCEPTEST-CA,DC=sceptest,DC=qe
	subject: CN=yttrium.idmqe.lab.eng.bos.redhat.com
	expires: 2017-08-09 10:42:31 UTC
	dns: yttrium.idmqe.lab.eng.bos.redhat.com
	key usage: digitalSignature,keyEncipherment
	eku: iso.org.dod.internet.security.mechanisms.8.2.2
	certificate template/profile: IPSECIntermediateOffline
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
[root@yttrium ~]#
Comment 8 errata-xmlrpc 2015-11-19 06:59:11 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.

https://rhn.redhat.com/errata/RHBA-2015-2365.html

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