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 1131907 - [ipa-client-install] cannot write certificate file '/etc/ipa/ca.crt.new': must be string or buffer, not None
Summary: [ipa-client-install] cannot write certificate file '/etc/ipa/ca.crt.new': mus...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-20 09:20 UTC by Jiri Belka
Modified: 2016-01-28 19:48 UTC (History)
8 users (show)

Fixed In Version: ipa-4.2.0-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:00:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
ipaclient-install.log (7.88 KB, text/x-log)
2014-08-20 09:20 UTC, Jiri Belka
no flags Details
ipaupgrade.log (15.48 MB, application/octet-stream)
2014-09-01 08:45 UTC, Jiri Belka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2362 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2015-11-19 10:40:46 UTC

Description Jiri Belka 2014-08-20 09:20:25 UTC
Created attachment 928738 [details]
ipaclient-install.log

Description of problem:

# ipa-client-install --domain brq-ipa.rhev.lab.eng.brq.redhat.com --server brq-ipa.rhev.lab.eng.brq.redhat.com --mkhomedir
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of
 failure.
Proceed with fixed values and no DNS discovery? [no]: yes
Hostname: jb-rhel7.rhev.lab.eng.brq.redhat.com
Realm: BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM
DNS Domain: brq-ipa.rhev.lab.eng.brq.redhat.com
IPA Server: brq-ipa.rhev.lab.eng.brq.redhat.com
BaseDN: dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for admin.LAB.ENG.BRQ.REDHAT.COM: 
cannot write certificate file '/etc/ipa/ca.crt.new': must be string or buffer, not None
Installation failed. Rolling back changes.
IPA client is not configured on this system.

...
2014-08-20T09:17:28Z DEBUG trying to retrieve CA cert via LDAP from brq-ipa.rhev.lab.eng.brq.redhat.com
2014-08-20T09:17:28Z DEBUG flushing ldap://brq-ipa.rhev.lab.eng.brq.redhat.com:389 from SchemaCache
2014-08-20T09:17:28Z DEBUG retrieving schema for SchemaCache url=ldap://brq-ipa.rhev.lab.eng.brq.redhat.com:389 conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x18a59e0>
2014-08-20T09:17:28Z DEBUG cannot write certificate file '/etc/ipa/ca.crt.new': must be string or buffer, not None
2014-08-20T09:17:28Z ERROR cannot write certificate file '/etc/ipa/ca.crt.new': must be string or buffer, not None
2014-08-20T09:17:28Z ERROR Installation failed. Rolling back changes.
2014-08-20T09:17:28Z ERROR IPA client is not configured on this system.
...

Version-Release number of selected component (if applicable):
ipa-python-3.3.3-28.el7.x86_64
ipa-client-3.3.3-28.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. ipa-client-install --domain brq-ipa.rhev.lab.eng.brq.redhat.com --server brq-ipa.rhev.lab.eng.brq.redhat.com --mkhomedir
2.
3.

Actual results:
failure

Expected results:
should work

Additional info:
workaround:
- ssh root.lab.eng.brq.redhat.com 'openssl x509 -in /etc/pki/tls/certs/ca.crt -text' > /tmp/out.crt
- add '--ca-cert-file=/tmp/out.crt' as arg for ipa-client-install

Comment 2 Martin Kosek 2014-08-20 10:54:20 UTC
It looks like it cannot find the certificate in IPA LDAP. Can you try to search and check what is the result of:

$ ldapsearch -h `hostname` -D "uid=admin,cn=users,cn=accounts,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" -x -W -b 'cn=CAcert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'

?

Comment 3 Jiri Belka 2014-08-20 11:44:46 UTC
[root@brq-ipa ~]# ldapsearch -h `hostname` -D "uid=admin,cn=users,cn=accounts,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" -x -W -b 'cn=CAcert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'
Enter LDAP Password: 
ldap_bind: Invalid credentials (49)

[root@brq-ipa ~]# ldapsearch -h `hostname` -D "uid=admin,cn=users,cn=accounts,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" -x -W -b 'cn=CAcert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <cn=CAcert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# CACert, ipa, etc, brq-ipa.rhev.lab.eng.brq.redhat.com
dn: cn=CACert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,
 dc=com
objectClass: nsContainer
objectClass: pkiCA
objectClass: top
cn: CAcert
cACertificate;binary:

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Comment 4 Martin Kosek 2014-08-20 14:12:39 UTC
I wonder how that could have happened that cACertificate attribute is filled, but empty. Is it a new FreeIPA installation or was it an upgrade from some older one? Is this reproducible?

BTW to workaround your issue on the server, you would need to let it re-create the CACert entry using couple steps:

# ldapdelete -h `hostname` -D "cn=Directory Manager" -x -W cn=CAcert,cn=ipa,cn=etc,dc=brq-ipa,dc=rhev,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
# ipa-ldap-updater --upgrade

After this step, ldapsearch from Comment 2 should return a proper value and installation should continue.

Comment 6 Martin Kosek 2014-08-26 10:02:52 UTC
Adding needinfo until we find some way how to reproduce it or diagnose how it could have happened.

Comment 7 Jiri Belka 2014-09-01 08:43:57 UTC
It seems the issue is related to following lines...

2014-09-01T08:35:41Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
2014-09-01T08:35:41Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-BRQ-IPA-RHEV-LAB-ENG-BRQ-REDHAT-COM/ -L -n CN=BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM Certificate Authority -a
2014-09-01T08:35:41Z DEBUG stdout=
2014-09-01T08:35:41Z DEBUG stderr=certutil: Could not find cert: CN=BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM Certificate Authority
: PR_FILE_NOT_FOUND_ERROR: File not found


full log in attachment.

Comment 8 Jiri Belka 2014-09-01 08:45:29 UTC
Created attachment 933279 [details]
ipaupgrade.log

Comment 9 Martin Kosek 2014-09-01 08:54:47 UTC
Honzo, could this be related IPA not being able to fetch certificates with longer name from certutil?

I.e. https://fedorahosted.org/freeipa/ticket/4453

Comment 12 Jan Cholasta 2014-09-01 14:45:50 UTC
(In reply to Martin Kosek from comment #9)
> Honzo, could this be related IPA not being able to fetch certificates with
> longer name from certutil?
> 
> I.e. https://fedorahosted.org/freeipa/ticket/4453

No, that bug is triggered only for certificate with nicknames longer than 61 characters.

I think the upload_cacrt update plugin is to blame - it looks for a certificate nicknamed "$REALM Certificate Authority" unconditionally, which will not work in CA-less installs.

Jiri, is your install CA-less (i.e. did you use the --http_pkcs12 and --dirsrv_pkcs12 options when you run ipa-server-install)? Can you please post the output of "certutil -d /etc/dirsrv/slapd-BRQ-IPA-RHEV-LAB-ENG-BRQ-REDHAT-COM -L"?

Comment 13 Jiri Belka 2014-09-01 14:49:56 UTC
I'm just user of this IPA server but pstehlik@ told me he could not install it but then he was successful with help of mkosek@. It can be possible that CA-less install is what we have.

# certutil -d /etc/dirsrv/slapd-BRQ-IPA-RHEV-LAB-ENG-BRQ-REDHAT-COM -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM IPA CA                   CT,,C
Server-Cert                                                  u,u,u

Comment 14 Martin Kosek 2014-09-12 08:06:01 UTC
Honza, it may have happened that it was a --selfsign installation that was then later converted to CA-less automatically. Do I read Comment 12 correctly that you have identified a bug in FreeIPA code and we should thus create an upstream ticket?

Comment 15 Jan Cholasta 2014-09-12 11:32:15 UTC
Yes, I think --selfsign is involved, but I have not yet exactly identified the bug.

Looking at the upgrade log, I can see the empty certificate got into LDAP during the upgrade, in the upload_cacrt update plugin. The plugin should have looked for a certificate named "$REALM IPA CA" (which you can see in the certutil output in comment 13), but it looked for "$REALM Certificate Authority" instead. Ever since upload_cacrt was introduced, "$REALM Certificate Authority" is not used anywhere in the related code, so I can only guess there was some mixup with code from the IPA version the server was upgraded from.

Comment 16 Martin Kosek 2014-09-24 10:49:49 UTC
Cloning to FreeIPA Trac, this might be solved with latest Jan's patches. See thread:

[Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes

Comment 17 Martin Kosek 2014-09-24 10:51:40 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4565

Comment 22 Scott Poore 2015-09-30 20:49:58 UTC
So, how can we test this?  Do we need to setup rhel7.0 IPA and switch from self-signed to external CA and then upgrade?

Comment 23 Jan Cholasta 2015-10-01 05:36:12 UTC
1. Install IPA server
2. Delete all entries under cn=certificates,cn=ipa,cn=etc,$SUFFIX
3. Put empty string in cACertificate;binary in cn=CACert,cn=ipa,cn=etc,$SUFFIX
4. Check that ipa-client-install succeeds
5. Run ipa-server-upgrade on the server
6. Check that cn=certificates,cn=ipa,cn=etc,$SUFFIX has been repopulated and that cn=CACert,cn=ipa,cn=etc,$SUFFIX has a non-empty cACertificate;binary

Comment 24 Scott Poore 2015-10-01 12:36:07 UTC
Do I just test this on RHEL7.2 or should I start earlier?

Is #4 on a different host I'm assuming?

Thanks,
Scott

Comment 25 Jan Cholasta 2015-10-01 13:16:26 UTC
You can do this with RHEL 7.2 server. Step 4 has to be done on different (client) host.

Comment 26 Scott Poore 2015-10-01 14:50:34 UTC
Verified.

Version ::

ipa-server-4.2.0-12.el7.x86_64

Results ::

[root@master yum.repos.d]# ipa-server-install --setup-dns --forwarder=192.168.122.1 --hostname=master.testrelm.test --ip-address=192.168.122.72 -n testrelm.test -r TESTRELM.TEST -a Secret123 -p Secret123 -U

... install looks normal  ...

[root@master ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test"
dn: cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test
objectClass: nsContainer
objectClass: top
cn: certificates

dn: cn=TESTRELM.TEST IPA CA,cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4
cn: TESTRELM.TEST IPA CA
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=Certificate Authority,O=TESTRELM.TEST
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsaamGbJVI+pHwMDca4A
 x6/WAutX3NG8FG0qktxxe1B5Q/fJhEArJ8TYv2VEnIXlC14/rJpeUWXWgU2B1f6syus/4JE1wYwWJ
 WAO/xeE5PUjfHdqvUjw7mqCxF0isrO33cgmFzuFApyxOXxo7yEnzsNwLanc5lkaV7lkH/J3ullgMA
 J/xrHlT3jWMfUCd9dIT4RRMqMSIcTXDVEav7o93+/cM7+C/KD54jzVEII6E4dA2fAXZxPhDXGUXrZ
 /uYiN8qegvILYVgLRyT0l3OSZ5ngH9Z8wE5h0X0qLTOU58jsBoHKt7bu44NS/JUnwC7D6xb5wgi/W
 Pr1y07wXIBSYs0QIDAQAB
cACertificate;binary:: MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQ
 KDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUxMDAx
 MTMzNjQ0WhcNMzUxMDAxMTMzNjQ0WjA4MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDD
 BVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxpq
 YZslUj6kfAwNxrgDHr9YC61fc0bwUbSqS3HF7UHlD98mEQCsnxNi/ZUScheULXj+sml5RZdaBTYHV
 /qzK6z/gkTXBjBYlYA7/F4Tk9SN8d2q9SPDuaoLEXSKys7fdyCYXO4UCnLE5fGjvISfOw3AtqdzmW
 RpXuWQf8ne6WWAwAn/GseVPeNYx9QJ310hPhFEyoxIhxNcNURq/uj3f79wzv4L8oPniPNUQgjoTh0
 DZ8BdnE+ENcZRetn+5iI3yp6C8gthWAtHJPSXc5JnmeAf1nzATmHRfSotM5TnyOwGgcq3tu7jg1L8
 lSfALsPrFvnCCL9Y+vXLTvBcgFJizRAgMBAAGjgagwgaUwHwYDVR0jBBgwFoAUUod/Oprevb3Bu3f
 Vydhdfx8b2U0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFFKHfzqa
 3r29wbt31cnYXX8fG9lNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL21hc3Rlc
 i50ZXN0cmVsbS50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFF8qiRhjiarAaqliP
 cp5Cm2YZ1jqpK2jDi2PlszM/mnL/QDiD+Jl5P0APgPAGbnrnmxZRuSXcZDLjnIUMt0Mq1kSMOra/g
 K5e5ivMyvNp/r3MdUAtUjmu6ott5iqoMDPjDOVeOqEDv2i6Trtrpj5NhtRYNQ0jxJJ/GW0oYLql+L
 HKkkj8dxpsnB6dPLGiguLx4xcsrV/wOiMNwtznmsXiEMdwGIpd77aUtyNWXOzl7iZT37NhuDV1WZC
 d6IXACAGaGSIanbSDfAbXIhhaHzy62UwfFZBYiPWUjGR2y1RfersZwJ388us1sNxM252me8KTD+bF
 kDZEvYbO/DM2RBEso=
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=Certificate Authority,O=TESTRELM.TEST;1
ipaConfigString: compatCA
ipaConfigString: ipaCA

[root@master ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test"|grep ^dn
dn: cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test
dn: cn=TESTRELM.TEST IPA CA,cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test

[root@master ~]# ldapdelete -x -D "cn=Directory Manager" -w Secret123 "cn=TESTRELM.TEST IPA CA,cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test"

[root@master ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=CACert,cn=ipa,cn=etc,dc=testrelm,dc=test"
dn: cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test
objectClass: nsContainer
objectClass: pkiCA
objectClass: top
cn: CAcert
cACertificate;binary:: MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQ
 KDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUxMDAx
 MTMzNjQ0WhcNMzUxMDAxMTMzNjQ0WjA4MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDD
 BVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxpq
 YZslUj6kfAwNxrgDHr9YC61fc0bwUbSqS3HF7UHlD98mEQCsnxNi/ZUScheULXj+sml5RZdaBTYHV
 /qzK6z/gkTXBjBYlYA7/F4Tk9SN8d2q9SPDuaoLEXSKys7fdyCYXO4UCnLE5fGjvISfOw3AtqdzmW
 RpXuWQf8ne6WWAwAn/GseVPeNYx9QJ310hPhFEyoxIhxNcNURq/uj3f79wzv4L8oPniPNUQgjoTh0
 DZ8BdnE+ENcZRetn+5iI3yp6C8gthWAtHJPSXc5JnmeAf1nzATmHRfSotM5TnyOwGgcq3tu7jg1L8
 lSfALsPrFvnCCL9Y+vXLTvBcgFJizRAgMBAAGjgagwgaUwHwYDVR0jBBgwFoAUUod/Oprevb3Bu3f
 Vydhdfx8b2U0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFFKHfzqa
 3r29wbt31cnYXX8fG9lNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL21hc3Rlc
 i50ZXN0cmVsbS50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFF8qiRhjiarAaqliP
 cp5Cm2YZ1jqpK2jDi2PlszM/mnL/QDiD+Jl5P0APgPAGbnrnmxZRuSXcZDLjnIUMt0Mq1kSMOra/g
 K5e5ivMyvNp/r3MdUAtUjmu6ott5iqoMDPjDOVeOqEDv2i6Trtrpj5NhtRYNQ0jxJJ/GW0oYLql+L
 HKkkj8dxpsnB6dPLGiguLx4xcsrV/wOiMNwtznmsXiEMdwGIpd77aUtyNWXOzl7iZT37NhuDV1WZC
 d6IXACAGaGSIanbSDfAbXIhhaHzy62UwfFZBYiPWUjGR2y1RfersZwJ388us1sNxM252me8KTD+bF
 kDZEvYbO/DM2RBEso=


[root@master ~]# ldapmodify -D "cn=Directory Manager" -w Secret123 <<EOF
dn: cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test
changetype: delete
EOF                     
deleting entry "cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test"

[root@master ~]# ldapmodify -D "cn=Directory Manager" -w Secret123 <<EOF
dn: cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test
changetype: add
objectClass: nsContainer
objectClass: pkiCA
objectClass: top
cn: CAcert
cACertificate;binary:
> EOF
adding new entry "cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test"


[root@master ~]# ldapsearch -D "cn=Directory Manager" -w Secret123 -b "cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test"
# extended LDIF
#
# LDAPv3
# base <cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# CAcert, ipa, etc, testrelm.test
dn: cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test
objectClass: nsContainer
objectClass: pkiCA
objectClass: top
cn: CAcert
cACertificate;binary:

# search result
search: 2
result: 0 Success


################################################################
# Now running on CLIENT
################################################################

[root@client yum.repos.d]# ipa-client-install -w Secret123 -p admin 
Discovery was successful!
Client hostname: client.testrelm.test
Realm: TESTRELM.TEST
DNS Domain: testrelm.test
IPA Server: master.testrelm.test
BaseDN: dc=testrelm,dc=test

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Attempting to sync time using ntpd.  Will timeout after 15 seconds
Unable to download CA cert from LDAP.
Do you want to download the CA cert from http://master.testrelm.test/ipa/config/ca.crt?
(this is INSECURE) [no]: yes
Downloading the CA certificate via HTTP, this is INSECURE
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=TESTRELM.TEST
    Issuer:      CN=Certificate Authority,O=TESTRELM.TEST
    Valid From:  Thu Oct 01 13:36:44 2015 UTC
    Valid Until: Mon Oct 01 13:36:44 2035 UTC

Enrolled in IPA realm TESTRELM.TEST
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm TESTRELM.TEST
trying https://master.testrelm.test/ipa/json
Forwarding 'ping' to json server 'https://master.testrelm.test/ipa/json'
Forwarding 'ca_is_enabled' to json server 'https://master.testrelm.test/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (client.testrelm.test) does not have A/AAAA record.
Missing reverse record(s) for address(es): 192.168.122.73.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Forwarding 'host_mod' to json server 'https://master.testrelm.test/ipa/json'
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring testrelm.test as NIS domain.
Client configuration complete.

################################################################
# Now running on MASTER
################################################################

[root@master ~]# ipa-server-upgrade
Upgrading IPA:
  [1/10]: stopping directory server
  [2/10]: saving configuration
  [3/10]: disabling listeners
  [4/10]: enabling DS global lock
  [5/10]: starting directory server
  [6/10]: updating schema
  [7/10]: upgrading server
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server
Done.
Update complete
Upgrading IPA services
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
Publish directory already set to new location
/etc/dirsrv/slapd-TESTRELM-TEST/certmap.conf is now managed by IPA. It will be overwritten. A backup of the original will be made.
[Verifying that CA proxy configuration is correct]
[Verifying that KDC configuration is using ipa-kdb backend]
[Fix DS schema file syntax]
[Removing RA cert from DS NSS database]
[Enable sidgen and extdom plugins by default]
[Updating mod_nss protocol versions]
[Fixing trust flags in /etc/httpd/alias]
[Exporting KRA agent PEM file]
KRA is not installed
[Removing self-signed CA]
[Checking for deprecated KDC configuration files]
[Checking for deprecated backups of Samba configuration files]
[Setting up Firefox extension]
[Add missing CA DNS records]
[Removing deprecated DNS configuration options]
[Ensuring minimal number of connections]
[Enabling serial autoincrement in DNS]
[Updating GSSAPI configuration in DNS]
[Updating pid-file configuration in DNS]
[Enabling "dnssec-enable" configuration in DNS]
[Setting "bindkeys-file" option in named.conf]
[Including named root key in named.conf]
[Masking named]
[Fix bind-dyndb-ldap IPA working directory]
Changes to named.conf have been made, restart named
[Upgrading CA schema]
CA schema update complete (no changes)
[Verifying that CA audit signing cert has 2 year validity]
[Update certmonger certificate renewal configuration to version 3]
Certmonger certificate renewal configuration is already at version 3
[Enable PKIX certificate path discovery and validation]
[Authorizing RA Agent to modify profiles]
pki-ca configuration changed, restart pki-ca
[Ensuring CA is using LDAPProfileSubsystem]
[Ensuring presence of included profiles]
[Add default CA ACL]
The IPA services were upgraded
The ipa-server-upgrade command was successful


[root@master ~]# ldapsearch -D "cn=Directory Manager" -w Secret123 -b "cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test"
# extended LDIF
#
# LDAPv3
# base <cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# CAcert, ipa, etc, testrelm.test
dn: cn=CAcert,cn=ipa,cn=etc,dc=testrelm,dc=test
objectClass: nsContainer
objectClass: pkiCA
objectClass: top
cn: CAcert
cACertificate;binary:: MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQ
 KDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUxMDAx
 MTMzNjQ0WhcNMzUxMDAxMTMzNjQ0WjA4MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDD
 BVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxpq
 YZslUj6kfAwNxrgDHr9YC61fc0bwUbSqS3HF7UHlD98mEQCsnxNi/ZUScheULXj+sml5RZdaBTYHV
 /qzK6z/gkTXBjBYlYA7/F4Tk9SN8d2q9SPDuaoLEXSKys7fdyCYXO4UCnLE5fGjvISfOw3AtqdzmW
 RpXuWQf8ne6WWAwAn/GseVPeNYx9QJ310hPhFEyoxIhxNcNURq/uj3f79wzv4L8oPniPNUQgjoTh0
 DZ8BdnE+ENcZRetn+5iI3yp6C8gthWAtHJPSXc5JnmeAf1nzATmHRfSotM5TnyOwGgcq3tu7jg1L8
 lSfALsPrFvnCCL9Y+vXLTvBcgFJizRAgMBAAGjgagwgaUwHwYDVR0jBBgwFoAUUod/Oprevb3Bu3f
 Vydhdfx8b2U0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFFKHfzqa
 3r29wbt31cnYXX8fG9lNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL21hc3Rlc
 i50ZXN0cmVsbS50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFF8qiRhjiarAaqliP
 cp5Cm2YZ1jqpK2jDi2PlszM/mnL/QDiD+Jl5P0APgPAGbnrnmxZRuSXcZDLjnIUMt0Mq1kSMOra/g
 K5e5ivMyvNp/r3MdUAtUjmu6ott5iqoMDPjDOVeOqEDv2i6Trtrpj5NhtRYNQ0jxJJ/GW0oYLql+L
 HKkkj8dxpsnB6dPLGiguLx4xcsrV/wOiMNwtznmsXiEMdwGIpd77aUtyNWXOzl7iZT37NhuDV1WZC
 d6IXACAGaGSIanbSDfAbXIhhaHzy62UwfFZBYiPWUjGR2y1RfersZwJ388us1sNxM252me8KTD+bF
 kDZEvYbO/DM2RBEso=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


[root@master ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test"
dn: cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test
objectClass: nsContainer
objectClass: top
cn: certificates

dn: cn=TESTRELM.TEST IPA CA,cn=certificates,cn=ipa,cn=etc,dc=testrelm,dc=test
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4
cn: TESTRELM.TEST IPA CA
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=Certificate Authority,O=TESTRELM.TEST
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsaamGbJVI+pHwMDca4A
 x6/WAutX3NG8FG0qktxxe1B5Q/fJhEArJ8TYv2VEnIXlC14/rJpeUWXWgU2B1f6syus/4JE1wYwWJ
 WAO/xeE5PUjfHdqvUjw7mqCxF0isrO33cgmFzuFApyxOXxo7yEnzsNwLanc5lkaV7lkH/J3ullgMA
 J/xrHlT3jWMfUCd9dIT4RRMqMSIcTXDVEav7o93+/cM7+C/KD54jzVEII6E4dA2fAXZxPhDXGUXrZ
 /uYiN8qegvILYVgLRyT0l3OSZ5ngH9Z8wE5h0X0qLTOU58jsBoHKt7bu44NS/JUnwC7D6xb5wgi/W
 Pr1y07wXIBSYs0QIDAQAB
cACertificate;binary:: MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQ
 KDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUxMDAx
 MTMzNjQ0WhcNMzUxMDAxMTMzNjQ0WjA4MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDD
 BVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxpq
 YZslUj6kfAwNxrgDHr9YC61fc0bwUbSqS3HF7UHlD98mEQCsnxNi/ZUScheULXj+sml5RZdaBTYHV
 /qzK6z/gkTXBjBYlYA7/F4Tk9SN8d2q9SPDuaoLEXSKys7fdyCYXO4UCnLE5fGjvISfOw3AtqdzmW
 RpXuWQf8ne6WWAwAn/GseVPeNYx9QJ310hPhFEyoxIhxNcNURq/uj3f79wzv4L8oPniPNUQgjoTh0
 DZ8BdnE+ENcZRetn+5iI3yp6C8gthWAtHJPSXc5JnmeAf1nzATmHRfSotM5TnyOwGgcq3tu7jg1L8
 lSfALsPrFvnCCL9Y+vXLTvBcgFJizRAgMBAAGjgagwgaUwHwYDVR0jBBgwFoAUUod/Oprevb3Bu3f
 Vydhdfx8b2U0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFFKHfzqa
 3r29wbt31cnYXX8fG9lNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL21hc3Rlc
 i50ZXN0cmVsbS50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFF8qiRhjiarAaqliP
 cp5Cm2YZ1jqpK2jDi2PlszM/mnL/QDiD+Jl5P0APgPAGbnrnmxZRuSXcZDLjnIUMt0Mq1kSMOra/g
 K5e5ivMyvNp/r3MdUAtUjmu6ott5iqoMDPjDOVeOqEDv2i6Trtrpj5NhtRYNQ0jxJJ/GW0oYLql+L
 HKkkj8dxpsnB6dPLGiguLx4xcsrV/wOiMNwtznmsXiEMdwGIpd77aUtyNWXOzl7iZT37NhuDV1WZC
 d6IXACAGaGSIanbSDfAbXIhhaHzy62UwfFZBYiPWUjGR2y1RfersZwJ388us1sNxM252me8KTD+bF
 kDZEvYbO/DM2RBEso=
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=Certificate Authority,O=TESTRELM.TEST;1
ipaConfigString: ipaCa

Comment 27 errata-xmlrpc 2015-11-19 12:00:54 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://rhn.redhat.com/errata/RHBA-2015-2362.html


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