#4397 IPA Install fails using external signed Certs - IndexError: list index out of range
Closed: Fixed None Opened 9 years ago by mkosek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1111320

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:

IPA Install is failing when using a external Active Directory signed Certs.
Seeing a ?IndexError: list index out of range? error

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

ipa-server-3.3.3-28.el7

How reproducible:

Always

Steps to Reproduce:

#  ipa-server-install --setup-dns --forwarder=10.0.0.1 -p Secret123 -a
Secret123 -r EXAMPLE.COM -n example.com --hostname
ipaserver.example.com --external-ca -U

We then copy the text of the created certificate /root/ipa.csr to the Windows
certificate server.  When creating the certificate we select "Request a
certificate" -> "advanced certificate request" -> "Submit a certificate request
by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by
using a base-64-encoded PKCS #7 file."

We then paste the contents of the csr file and select "Subordinate Certificate
Authority" from the Template dropdown.

When saving the output we select base 64 encoded.

Based on previous attempts we convert the PK7 CA chain file to PEM via the
following:


# openssl pkcs7 -print_certs -in certnew.p7b -out
ca-certs.pem

We then attempt the second step of the installation with the following:

ipa-server-install --external_cert_file=ipaserver_b64.cer

--external_ca_file=/root/ca-certs.pem

Actual results:
[16/22]: restarting certificate server
[17/22]: requesting RA certificate from CA
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range

Additional info:

From ipaserver-install logs I see the following

2014-06-18T18:44:01Z DEBUG Starting external process
2014-06-18T18:44:01Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f
XXXXXXXX -R -k rsa -g 2048 -s CN=IPA RA,O=EXAMPLE.COM -z /tmp/tmprLwjEW
-a
2014-06-18T18:44:02Z DEBUG Process finished, return code=0
2014-06-18T18:44:02Z DEBUG stdout=
Certificate request generated by Netscape certutil
Phone: (not specified)

Common Name: IPA RA
Email: (not specified)
Organization: LINUX.EXAMPLE.COM
State: (not specified)
Country: (not specified)

-----BEGIN NEW CERTIFICATE REQUEST-----
...
-----END NEW CERTIFICATE REQUEST-----

2014-06-18T18:44:02Z DEBUG stderr=

Generating key. This may take a few moments...

2014-06-18T18:44:02Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638,
in run_script
return_value = main_function()

File "/usr/sbin/ipa-server-install", line 1094, in main
subject_base=options.subject)

File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
478, in configure_instance
self.start_creation(runtime=210)

File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
364, in start_creation
method()

File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
1089, in __request_ra_certificate
self.requestId = item_node[0].childNodes[0].data

2014-06-18T18:44:02Z DEBUG The ipa-server-install command failed, exception:
IndexError: list index out of range

From CA debug logs:

[18/Jun/2014:14:44:01]http-bio-8443-exec-2: according to ccMode,
authorization for servlet: caGetStatus is LDAP based, not XML {1}, use default
authz mgr: {2}.
[18/Jun/2014:14:44:01]http-bio-8443-exec-2: CMSServlet:service() uri =
/ca/admin/ca/getStatus
[18/Jun/2014:14:44:01]http-bio-8443-exec-2: CMSServlet: caGetStatus start to
service.
[18/Jun/2014:14:44:01]http-bio-8443-exec-2: CMSServlet: curDate=Wed Jun 18
14:44:01 EDT 2014 id=caGetStatus time=169
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: according to ccMode,
authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use
default authz mgr: {2}.
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: according to ccMode,
authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use
default authz mgr: {2}.
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet:service() uri =
/ca/ee/ca/profileSubmit
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet::service() param
name='xmlOutput' value='true'
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet::service() param
name='requestor_name' value='IPA Installer'
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet::service() param
name='profileId' value='caServerCert'
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet::service() param
name='cert_request_type' value='pkcs10'
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet::service() param
name='cert_request'
value='...'
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet: caProfileSubmit start
to service.
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: xmlOutput true
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: ProfileSubmitServlet: isRenewal
false
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: according to ccMode,
authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use
default authz mgr: {2}.
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: Profile caServerCert Not Found
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: ProfileSubmitServlet: bad data
provided in processing request: Profile caServerCert Not Found
[18/Jun/2014:14:44:02]http-bio-8080-exec-2: CMSServlet: curDate=Wed Jun 18
14:44:02 EDT 2014 id=caProfileSubmit time=21

From looking at older BZ it looks like it does not like the cert it trying to
sign. I am not sure this is the problem but I noticed in ca debug logs that it
does have a ^M in it.


Based on analysis of the logs in this bug:

  1. The cert request fails because the CA fails to come up properly.
  2. This happens because a self test fails.
  3. The self test failed because the CA Cert chain - which is provided in a file in step 2 of the install
    fails to be imported correctly. We've seen this in windows cases.
  4. Dogtag expects to get PKCS7 input for the cert chain.
  5. IPA expects and enforces a series of certs in PEM format.
  6. If you comment out the IPA PEM format test and allow the original pkcs7 cert chain to go through to
    the dogtag installer, then the installation is successful.

So, the basic problem is that IPA enforces that the cert chain must be in PEM format, and Dogtag expects (and has always expected) pkcs7.

Updating the milestone, this ticket should have gone to 4.0.1.

FreeIPA 4.0.1 was released, moving to next bugfixing release milestone.

Fixed; waiting for a test.

master:

  • 359dfe5 Convert external CA chain to PKCS#7 before passing it to pkispawn.

ipa-4-1:

  • 359dfe5 Convert external CA chain to PKCS#7 before passing it to pkispawn.

ipa-4-0:

  • 7c03ef0 Convert external CA chain to PKCS#7 before passing it to pkispawn.

Code is fixed and verified by downstream QA. So I will just close this ticket.

A request to add tests is tracked separately, in #4519.

Metadata Update from @mkosek:
- Issue assigned to jcholast
- Issue set to the milestone: FreeIPA 4.0.2

7 years ago

Login to comment on this ticket.

Metadata