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 1759281 - getcert with -F option returns before cacert file is created
Summary: getcert with -F option returns before cacert file is created
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Thomas Woerner
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-07 18:17 UTC by Ade Lee
Modified: 2023-04-11 16:47 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1769282 (view as bug list)
Environment:
Last Closed: 2020-04-28 15:43:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-9671 0 None None None 2023-04-11 16:47:50 UTC
Red Hat Issue Tracker RHELPLAN-30568 0 None None None 2023-04-11 16:45:30 UTC
Red Hat Product Errata RHEA-2020:1640 0 None None None 2020-04-28 15:43:59 UTC

Description Ade Lee 2019-10-07 18:17:32 UTC 
Description of problem:

When getcert is invoked with the -F option, it is supposed to store the CA cert in a file.

When invoked with the -w option, it will wait until the cert is issued.  But it will occasionally also return before the CA cert file is written.

This causes issues when trying to invoke certmonger from puppet-certmonger for instance, because subsequent calls that rely on the existence of that file (to change its permissions for instance) will fail.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Rob Crittenden 2019-10-25 13:55:54 UTC 
We narrowed this down to the following:

1. certmonger is started prior to ipa-client-install.
2. IPA is unconfigured so it doesn't know where to fetch the chain from. The CA goes into a pending status to try again.
3. The machine is enrolled as an IPA client and certificate(s) retrieved using -F. Since the IPA CA still hasn't been set there is no CA file to write yet.
4. After a few hours certmonger wakes up the IPA CA again, it sees it is configured and retrieves the CA which results in writing the files pointed to by -F.

The fix is to restart certmonger after ipa-client-install.

Right now it is only started if ipa-client-install runs with --request-cert.

It should do a conditional restart on certmonger in all cases.
Comment 2 Rob Crittenden 2019-10-25 14:00:37 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/8105
Comment 3 Rob Crittenden 2019-11-07 18:01:33 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/1e3de172696a98914f77e50fd64bc8b63360cd27
https://pagure.io/freeipa/c/3593e5362206fd9287e97fe2cee229a1117811ff
Comment 4 Rob Crittenden 2019-11-07 19:47:52 UTC 
Fixed upstream
ipa-4-8:
https://pagure.io/freeipa/c/24e882f1daa149b89180ba93fc02e6d4a7fd3109
https://pagure.io/freeipa/c/6bac58ca5c32be4302707c1fb6f992faca84b77b
Comment 16 Rob Crittenden 2020-03-03 15:13:12 UTC 
Reproducer:

RHEL 7.7, 4.6.5-11.el7_7.4
* systemctl start certmonger
* ipa-client-install
* ipa-getcert request  -f /etc/pki/tls/certs/test.pem -k /etc/pki/tls/private/test.key -K test/`hostname` -F /etc/pki/tls/test.CA
* < it should more or less immediately be issued and be in MONITORING >
* ls -l /etc/pki/tls/test.CA
ls: cannot access /etc/pki/tls/test.CA: No such file or directory

If the tracking is in MONITORING and /etc/pki/tls/test.CA does not exist then you've reproduced it.

RHEL 8.x

Same sequence will result in test.CA showing up at the same time the request goes into MONITORING. I tested with ipa-client-4.8.4-6.module+el8.2.0+5773+68ace8c5.x86_64
Comment 17 Mohammad Rizwan 2020-03-04 09:44:38 UTC 
old version:

ipa-client-4.6.5-11.el7_7.4.x86_64


[root@client ~]# ipa-getcert request  -f /etc/pki/tls/certs/test.pem -k /etc/pki/tls/private/test.key -K test/`hostname` -F /etc/pki/tls/test.CA
New signing request "20200304093654" added.

[root@client ~]# getcert  list
Number of certificates and requests being tracked: 1.
Request ID '20200304093654':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/etc/pki/tls/private/test.key'
	certificate: type=FILE,location='/etc/pki/tls/certs/test.pem'
	CA: IPA
	issuer: CN=Certificate Authority,O=TESTRELM.TEST
	subject: CN=client.testrelm.test,O=TESTRELM.TEST
	expires: 2022-03-05 09:36:56 UTC
	dns: client.testrelm.test
	principal name: test/client.testrelm.test
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

[root@client ~]# ll /etc/pki/tls/test.CA
ls: cannot access /etc/pki/tls/test.CA: No such file or directory


Fixed version:
ipa-client-4.8.4-6.module+el8.2.0+5773+68ace8c5.x86_64


[root@client ~]#  ipa-getcert request  -f /etc/pki/tls/certs/test.pem -k /etc/pki/tls/private/test.key -K test/`hostname` -F /etc/pki/tls/test.CA
New signing request "20200304093841" added.

[root@client ~]# getcert list
Number of certificates and requests being tracked: 1.
Request ID '20200304093841':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/etc/pki/tls/private/test.key'
	certificate: type=FILE,location='/etc/pki/tls/certs/test.pem'
	CA: IPA
	issuer: CN=Certificate Authority,O=TESTRELM.TEST
	subject: CN=client.testrelm.test,O=TESTRELM.TEST
	expires: 2022-03-05 15:08:43 IST
	dns: client.testrelm.test
	principal name: test/client.testrelm.test
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
[root@client ~]# ll /etc/pki/tls/test.CA
-rw-------. 1 root root 1643 Mar  4 15:08 /etc/pki/tls/test.CA

Issue seems to be fixed, hence marking the bug as verified.
Comment 18 Florence Blanc-Renaud 2020-03-12 06:58:59 UTC 
Test Case provided upstream:  ipatests/test_integration/test_cert.py::TestInstallMasterClient::test_cacert_file_appear_with_option_F

master:
https://pagure.io/freeipa/c/6739d8722c4a3e84cdcf1e058c6fd15317ac0ca4
https://pagure.io/freeipa/c/9bcc57d9e01625a122811a50f78acde247b5791d

ipa-4-8:
https://pagure.io/freeipa/c/5d8d9198ce1ddfd44eb7c0268c397359e6239fca
https://pagure.io/freeipa/c/937fb1d9518c54bf9c05bc0b7d6f43b29971eb3c
Comment 20 errata-xmlrpc 2020-04-28 15:43:29 UTC 
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://access.redhat.com/errata/RHEA-2020:1640
Note You need to log in before you can comment on or make changes to this bug.