Bug 1759281
| Summary: | getcert with -F option returns before cacert file is created | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ade Lee <alee> | |
| Component: | ipa | Assignee: | Thomas Woerner <twoerner> | |
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 8.0 | CC: | frenaud, ggrasza, ksiddiqu, myusuf, nalin, pasik, pcech, rcritten, ssidhaye, tscherf | |
| Target Milestone: | rc | Keywords: | TestCaseProvided | |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1769282 (view as bug list) | Environment: | ||
| Last Closed: | 2020-04-28 15:43:29 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: | ||||
|
Description
Ade Lee
2019-10-07 18:17:32 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. Upstream ticket: https://pagure.io/freeipa/issue/8105 Fixed upstream master: https://pagure.io/freeipa/c/1e3de172696a98914f77e50fd64bc8b63360cd27 https://pagure.io/freeipa/c/3593e5362206fd9287e97fe2cee229a1117811ff Fixed upstream ipa-4-8: https://pagure.io/freeipa/c/24e882f1daa149b89180ba93fc02e6d4a7fd3109 https://pagure.io/freeipa/c/6bac58ca5c32be4302707c1fb6f992faca84b77b 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 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. 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 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 |