Bug 1408120
| Summary: | Certificate of managed-by host/service fails to resubmit | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Thorsten Scherf <tscherf> |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Kaleem <ksiddiqu> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.8 | CC: | frenaud, ipa-maint, jan.orel, jcholast, ksiddiqu, lkrispen, nsoman, pvoborni, rcritten, robert, sumenon, tbordaz, tscherf, vonsch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1269089 | Environment: | |
| Last Closed: | 2017-01-11 09:32:26 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
Thorsten Scherf
2016-12-22 08:34:51 UTC
Used version of 389-ds: Oct 03 09:13:26 Updated: 389-ds-base-1.2.11.15-75.el6_8.x86_64 The ACI errors are referring to ACIs defined in default-aci.ldif (/usr/share/ipa and then various updates files like 60-trusts.update, 40-delegation.update or 20-aci.update all in /usr/share/ipa/updates CCing Ludwig and Thierry - if it rings a bell. I think the acis reported are misleading, the deny is the default action if no aci allowing access is found, and the meassage " no aci matched the subject by aci(53):" indicates just that, so no explicite aci is denying access and no aci is allowing it, the aci reported in this case is, I think, just the last aci accessed and not specific for the deny. So we either have a case of incorrect aci evaluation or of missing acis. Can we get a list of all acis and what exact mods/searches are attempted and rejected. The error comes from a missing allowed write access to objectclass of the entry cn=retrieve certificate,cn=virtual operations,cn=etc,<suffix> The ACI to grant this access already exists: aci: (targetattr = "objectclass")(target = "ldap:///cn=retrieve certificate,cn=virtual operations,cn=etc,<suffix>" )(version 3.0 ; acl "permission:Retrieve Certificates from the CA" ; allow (write) groupdn = "ldap:///cn=Retrieve Certificates from the CA,cn=permissions,cn=pbac,<suffix>";) But in fact the group "cn=Retrieve Certificates from the CA,cn=permissions,cn=pbac,<suffix>" does not contain the host. Doing the following dn: cn=Retrieve Certificates from the CA,cn=permissions,cn=pbac,<suffix> changetype: modify add: member member: fqdn=<host_fqdn>,cn=computers,cn=accounts,<suffix> Allows to run successfully 'getcert list -i "<cert_req>" I do not know the ipa commands to add the host in that group I've a feeling that Thorsten's example from 2016-12-21 17:21:25 behaves correctly assuming that rhtestwww.testrelm.test is not a hostname of the ipa server. Hosts manage their certificates and certificates of their services with principal in their keytab. If the principal doesn't match principal of service's host entry the ACI error is correct behavior. Permissions are by default assigned through privileges and roles. The "Retrieve Certificate from the CA" permission has by default "Certificate Administrators" and "Host Administrators" privileges. Direct assignment is not a correct thing. Also I'd be careful with assigning these permissions to host principals because it might allow them to manage not only their certificates. Your explanation makes sense. If 'getcert list -i 20161221153757' should fail it is fine. It is failing because of a missing aci similar to "permission:Retrieve Certificates from the CA: aci: (targetattr = "objectclass")(target = "ldap:///cn=retrieve certificate,cn=virtual operations,cn=etc,<suffix>" )(version 3.0 ; acl "missing aci " ; allow (write) <bind_rule>;) (In reply to Petr Vobornik from comment #4) > I've a feeling that Thorsten's example from 2016-12-21 17:21:25 behaves > correctly assuming that rhtestwww.testrelm.test is not a hostname of the ipa > server. > > Hosts manage their certificates and certificates of their services with > principal in their keytab. > > If the principal doesn't match principal of service's host entry the ACI > error is correct behavior. > > Permissions are by default assigned through privileges and roles. The > "Retrieve Certificate from the CA" permission has by default "Certificate > Administrators" and "Host Administrators" privileges. Direct assignment is > not a correct thing. Also I'd be careful with assigning these permissions to > host principals because it might allow them to manage not only their > certificates. When this is expected behavior, why can then successfully request a certificate in the first place and see the failure only during renewal? Please see my last comment how to reproduce the issue. Also, when I hit the issue you described, I would expect to see an error like this: Insufficient access: hostname in subject of request 'dell-m620-05.testrelm.tes' does not match principal hostname 'rhtestwww.testrelm.test'). I will try to reproduce the issue also on RHEL7 when I'm back from pto. I forgot that we are talking about host which is managed by the other host. In that case it should work and it is a bug. The bug was fixed on RHEL 7 sometime between IPA 4.1 and IPA 4.4 release. In IPA 4.2, certificate ACIs underwent big changes with introduction of certificate profiles support. Therefore there is high chance that there is no patch which can be simply backported. Given that RHEL 6 is in production phase 2 I'd not fix the bug unless it's critical. If we won't fix this in RHEL6, we basically make it impossible to renew certificates which have been requested for a SAN [1]. Since the support for Kerberos principal alias has been introduced only in ipa-4.x - and there is even a bug in the current implementation [2] - the only way to request certificates for a host specified in the subjectAltName certificate extension is to use a procedure like the one described in [3]. But due to the bug reported here, this does not work (at least the renewal part does not work). A typical use case is shown in the KCS [3]. [1] http://www.freeipa.org/page/Apache_SNI_With_Kerberos [2] https://bugzilla.redhat.com/show_bug.cgi?id=1400529 [3] https://access.redhat.com/solutions/547723 |