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?

(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.

Created attachment 1058951 [details]
console output for csr at renewal time

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.

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 ~]#

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