Bug 1249753
| Summary: | challenge password not added in csr using start-tracking | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Kaleem <ksiddiqu> | ||||||
| Component: | certmonger | Assignee: | Jan Cholasta <jcholast> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Kaleem <ksiddiqu> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.2 | CC: | dkupka, mkosek, nalin, nsoman | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| URL: | https://git.fedorahosted.org/cgit/certmonger.git/commit/?h=certmonger-0.78-branch&id=a8f847f10f66fc6e0fea45a863827f67132b5fce | ||||||||
| Whiteboard: | |||||||||
| 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 11:59:11 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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 |
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.