Bug 1408120 - Certificate of managed-by host/service fails to resubmit
Summary: Certificate of managed-by host/service fails to resubmit
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.8
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Kaleem
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-22 08:34 UTC by Thorsten Scherf
Modified: 2017-01-23 08:12 UTC (History)
14 users (show)

(edit)
Clone Of: 1269089
(edit)
Last Closed: 2017-01-11 09:32:26 UTC


Attachments (Terms of Use)

Description Thorsten Scherf 2016-12-22 08:34:51 UTC
I'll keep the RHEL7 related data here in this RHEL6 bug for reference. The issue also has been observed on ipa-server-3.0.0-50.el6_8.3.x86_64. Please see the last comment (2016-12-21 17:21:25) for details and how to reproduce the issue.


+++ This bug was initially created as a clone of Bug #1269089 +++

Description of problem:
When trying to resubmit (or let the certmonger to resubmit before exp.) certificate of the host/service which is managed by the local host, it fails with ACI error.


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


How reproducible:
Always


Steps to Reproduce:
1. ipa-server-install -r test.com -n novalocal -p passwd123 -a passwd123 --ip-address=172.30.41.25 --ssh-trust-dns --hostname testsrv.novalocal --setup-dns --no-host-dns --no-forwarders
2. kinit admin
3. ipa host-add testhost --force
4. ipa host-add-managedby testhost.novalocal --host=testsrv.novalocal
5. ipa-getcert request -k /etc/ssl/certs/testhost.novalocal.key -f /etc/ssl/certs/testhost.novalocal.cert -N testhost.novalocal -K host/testhost.novalocal
6. ipa-getcert list
   ...
   Request ID '20151005150737':
   ... 
   status MONITORING ...
7. ipa-getcert resubmit -i 20151005150737
8. ipa-getcert list -i 20151005150737


Actual results:
Request ID '20151005150737':
	status: MONITORING
	ca-error: Server at https://testsrv.novalocal/ipa/xml denied our request, giving up: 2100 (RPC failed at server.  Insufficient access: not allowed to perform this command)

Expected results:
no ca-error

Additional info:
Whey remove userCertificate attribute from the mentioned host (woks also when kinited to the identity of the host/testsrv.novalocal). The next ipa-getcert resubmit works well.

--- Additional comment from RHEL Product and Program Management on 2015-10-06 12:07:21 CEST ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Jan Orel on 2015-10-08 16:08 CEST ---

Removing check which does not work well in case that host is resubmitting
certificate of different host/service that he can manage.

--- Additional comment from Petr Vobornik on 2015-10-13 12:18:48 CEST ---

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5363

--- Additional comment from Petr Vobornik on 2015-10-14 14:36:37 CEST ---

Please note that if this issue is fixed upstream it will most likely be a part of IdM in RHEL 7.3. Please open a support case if you want it backported to RHEL 7.1 or 7.2.

--- Additional comment from Petr Vobornik on 2016-05-06 16:58:38 CEST ---

According to https://fedorahosted.org/freeipa/ticket/5363#comment:4 it was fixed in 4.2 scope.

--- Additional comment from errata-xmlrpc on 2016-06-22 12:07:53 CEST ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2016:23646-01
https://errata.devel.redhat.com/advisory/23646

--- Additional comment from Sudhir Menon on 2016-09-20 12:09:30 CEST ---

Jan,

I tried the below steps and see "Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry"


[root@master samba]# ipa host-add testhost.test-relm.test --force
------------------------------------
Added host "testhost.test-relm.test"
------------------------------------
Host name: testhost.test-relm.test
Principal name: host/testhost.test-relm.test@TEST-RELM.TEST
Principal alias: host/testhost.test-relm.test@TEST-RELM.TEST
Password: False
Keytab: False
Managed by: testhost.test-relm.test
     
[root@master samba]# ipa host-add-managedby master.test-relm.test --host=testhost.test-relm.test
Host name: master.test-relm.test
Principal name: host/master.test-relm.test@TEST-RELM.TEST
Principal alias: host/master.test-relm.test@TEST-RELM.TEST
Member of host-groups: ipaservers
Managed by: master.test-relm.test, testhost.test-relm.test
-------------------------
Number of members added 1
-------------------------
     
[root@master samba]# mkdir -p /tmp/testhost
[root@master samba]# chcon -t cert_t /tmp/testhost/

[root@master samba]# ipa-getcert request -k /tmp/testhost/testhost.key -f /tmp/testhost/testhost.cert -N testhost.test-relm.test -K host/testhost.test-relm.test@TEST-RELM.TEST
New signing request "20160920100418" added.

[root@master samba]# ipa-getcert list -i 20160920100418
Number of certificates and requests being tracked: 9.
Request ID '20160920100418':
status: CA_REJECTED
ca-error: Server at https://master.test-relm.test/ipa/xml denied our request, giving up: 2100 (RPC failed at server.  Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'fqdn=testhost.test-relm.test,cn=computers,cn=accounts,dc=test-relm,dc=test'.).
stuck: yes
key pair storage: type=FILE,location='/tmp/testhost/testhost.key'
certificate: type=FILE,location='/tmp/testhost/testhost.cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes

--- Additional comment from Jan Cholasta on 2016-09-20 13:23:27 CEST ---

Sudhir,

with:

    # ipa host-add-managedby master.test-relm.test --host=testhost.test-relm.test

you allow testhost.test-relm.test to manage master.test-relm.test. Then, you try to request certificate for testhost.test-relm.test from master.test-relm.test, but that requires master.test-relm.test to manage testhost.test-relm.test, i.e. the other way around.

--- Additional comment from Sudhir Menon on 2016-09-20 14:00:25 CEST ---

Verified on RHEL73 using 
ipa-server-4.4.0-12.el7.x86_64
389-ds-base-1.3.5.10-11.el7.x86_64
certmonger-0.78.4-3.el7.x86_64

[root@master sssd]# mkdir -p /tmp/testhost
[root@master sssd]# chcon -t cert_t /tmp/testhost/
 
[root@master sssd]# ipa-getcert request -k /tmp/testhost/testhost.key -f /tmp/testhost/testhost.cert -N testhost.test-relm.test -K host/testhost.test-relm.test@TEST-RELM.TEST
New signing request "20160920115306" added.
 
[root@master sssd]# ipa-getcert list -i 20160920115306
Number of certificates and requests being tracked: 9.
Request ID '20160920115306':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/tmp/testhost/testhost.key'
certificate: type=FILE,location='/tmp/testhost/testhost.cert'
CA: IPA
issuer: CN=Certificate Authority,O=TEST-RELM.TEST
subject: CN=testhost.test-relm.test,O=TEST-RELM.TEST
expires: 2018-09-21 11:53:08 UTC
principal name: host/testhost.test-relm.test@TEST-RELM.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@master sssd]# ipa-getcert resubmit -i 20160920115306
Resubmitting "20160920115306" to "IPA".
[root@master sssd]# ipa-getcert list -i 20160920115306
Number of certificates and requests being tracked: 9.
Request ID '20160920115306':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/tmp/testhost/testhost.key'
certificate: type=FILE,location='/tmp/testhost/testhost.cert'
CA: IPA
issuer: CN=Certificate Authority,O=TEST-RELM.TEST
subject: CN=testhost.test-relm.test,O=TEST-RELM.TEST
expires: 2018-09-21 11:56:25 UTC
principal name: host/testhost.test-relm.test@TEST-RELM.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

--- Additional comment from errata-xmlrpc on 2016-11-02 16:09:35 CET ---

Bug report changed to RELEASE_PENDING status by Errata System.
Advisory RHBA-2016:23646-02 has been changed to PUSH_READY status.
https://errata.devel.redhat.com/advisory/23646

--- Additional comment from errata-xmlrpc on 2016-11-04 06:38:33 CET ---

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-2016-2404.html

--- Additional comment from Thorsten Scherf on 2016-12-21 17:21:25 CET ---

I need to re-open this because I can reproduce the issue with latest ipa-server on RHEL-6.8:

# rpm -q ipa-server
ipa-server-3.0.0-50.el6_8.3.x86_64

# ipa host-add rhtestwww.testrelm.test --ip-address 1.2.3.4
# ipa service-add HTTP/rhtestwww.testrelm.test@TESTRELM.TEST

# ipa host-add-managedby rhtestwww.testrelm.test --hosts `hostname`
# ipa service-add-host "HTTP/rhtestwww.testrelm.test@TESTRELM.TEST" --hosts `hostname` 

# mkdir /tmp/certs
# chcon -t cert_t /tmp/certs

# cd /tmp/certs
# ipa-getcert request -k $PWD/rhtestwww.testrelm.test.key -f $PWD/rhtestwww.testrelm.test.crt -K "HTTP/rhtestwww.testrelm.test@TESTRELM.TEST" -N "CN=rhtestwww.testrelm.test" -D "rhtestwww.testrelm.test"

# getcert list -i 20161221153757
Number of certificates and requests being tracked: 2.
Request ID '20161221153757':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/tmp/certs/rhtestwww.testrelm.test.key'
	certificate: type=FILE,location='/tmp/certs/rhtestwww.testrelm.test.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=TESTRELM.TEST
	subject: CN=rhtestwww.testrelm.test,O=TESTRELM.TEST
	expires: 2018-12-22 15:37:58 UTC
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

# ipa-getcert resubmit -i 20161221153757
Resubmitting "20161221153757" to "IPA".

# getcert list -i 20161221153757
Number of certificates and requests being tracked: 2.
Request ID '20161221153757':
	status: MONITORING
	ca-error: Server at https://dell-m620-05.testrelm.test/ipa/xml denied our request, giving up: 2100 (RPC failed at server.  Insufficient access: not allowed to perform this command).
	stuck: no
	key pair storage: type=FILE,location='/tmp/certs/rhtestwww.testrelm.test.key'
	certificate: type=FILE,location='/tmp/certs/rhtestwww.testrelm.test.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=TESTRELM.TEST
	subject: CN=rhtestwww.testrelm.test,O=TESTRELM.TEST
	expires: 2018-12-22 15:37:58 UTC
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

When I enable ACI logging, I see a number of deny entries:

# grep 11:09 /var/log/dirsrv/slapd-TESTRELM-TEST/errors|grep -i deny
[21/Dec/2016:11:09:06 -0500] NSACLPlugin - conn=24 op=6 (main): Deny read on entry(fqdn=dell-per430-28.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test).attr(krbPrincipalKey) to fqdn=dell-per430-28.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test: no aci matched the subject by aci(54): aciname= "Password change service can read/write passwords", acidn="dc=testrelm,dc=test"
[21/Dec/2016:11:09:06 -0500] NSACLPlugin - conn=0 op=0 (main): Deny add on entry(krbprincipalname=http/rhtestwww.testrelm.test@testrelm.test,cn=services,cn=accounts,dc=testrelm,dc=test).attr(NULL) to fqdn=dell-per430-28.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test: no aci matched the subject by aci(53): aciname= "Admins can write passwords", acidn="dc=testrelm,dc=test"
[21/Dec/2016:11:09:06 -0500] NSACLPlugin - conn=0 op=0 (main): Deny delete on entry(krbprincipalname=http/rhtestwww.testrelm.test@testrelm.test,cn=services,cn=accounts,dc=testrelm,dc=test).attr(NULL) to fqdn=dell-per430-28.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test: no aci matched the subject by aci(53): aciname= "Admins can write passwords", acidn="dc=testrelm,dc=test"
[21/Dec/2016:11:09:06 -0500] NSACLPlugin - conn=0 op=0 (main): Deny write on entry(krbprincipalname=http/rhtestwww.testrelm.test@testrelm.test,cn=services,cn=accounts,dc=testrelm,dc=test).attr(krbprincipalname) to fqdn=dell-per430-28.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test: no aci matched the resource
[...]

--- Additional comment from Thorsten Scherf on 2016-12-21 19:22:35 CET ---

Just figured this BZ is for RHEL7. I will open a new BZ against RHEL6 and attach relevant data there.

Comment 1 Petr Vobornik 2016-12-22 09:42:16 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.

Comment 2 Ludwig 2016-12-22 10:42:38 UTC
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.

Comment 3 thierry bordaz 2016-12-23 12:13:27 UTC
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

Comment 4 Petr Vobornik 2016-12-23 14:07:54 UTC
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.

Comment 5 thierry bordaz 2016-12-23 14:38:33 UTC
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>;)

Comment 6 Thorsten Scherf 2016-12-30 10:04:19 UTC
(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.

Comment 7 Petr Vobornik 2017-01-02 16:38:20 UTC
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.

Comment 8 Thorsten Scherf 2017-01-03 10:20:02 UTC
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


Note You need to log in before you can comment on or make changes to this bug.