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 1649550 - pki tomcat service fails to start after renewing expired certificates
Summary: pki tomcat service fails to start after renewing expired certificates
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-13 21:01 UTC by esawtelle
Modified: 2020-06-03 14:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-04 14:55:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description esawtelle 2018-11-13 21:01:49 UTC
Description of problem:  

We have 1 master server (CA) and 4 replica servers.

The RootRA certificates on the replica servers did not renew automatically.  We moved the date back on all the servers and performed the steps to renew the certs. The certs appear to be updated properly with valid expiration dates and report a status of Monitoring.  The date was moved forward to the current time and we verified the ipa services were up and running.  After rebooting the replicas two of the them are failing to start the pki-tomcatd service the other 2 are functioning properly.

One thing we had to do that was different from other post is we exported the rootra (ipaCert), ocsp subsystem, ca subsystem, and ca audit cert from the master and imported then into the replicas.

We have verified the /etc/pki/pki-tomcat/ca/CS.cfg file has the correct ca signing cert.

We have verified the httpd and pki-tomcat certs are updated with the correct certs and trust attributes.

We have verified the serial number from the RootRA certificate matches the ipara description object.

We have updated the krb5 keytab files. 


Version-Release number of selected component (if applicable):
Centos 7.2 SElinux=Enforcing
freeipa 4.2

Comment 2 Florence Blanc-Renaud 2018-11-14 12:55:26 UTC
Can you provide more information re. the error when trying to start pki-tomcat? Please upload Dogtag logs, as well as 389-ds logs.

Comment 3 esawtelle 2018-11-15 16:25:28 UTC
I am not able to transfer logs to this site easily.  Here is what we are seeing:

# ipactl -d restart
dirsrv active
krb5kdc active
kadmin active
named active
ipa_memchached active
httpd active
pki-tomcat active
wget ... https://server.domain.name:8443/ca/admin/ca/getStatus
return code=8
connecting to server.domain.name;8443 .... connected.
HTTP/1.1 404 Not Found
ERROR 404 Not Found.

It retries for 30 seconds then shuts down all the services.

I don't know what/where the dogtab log is?

There is no current logs in the /var/log/pki/pki-tomcat/ca directory.

The only log in /var/log/pki/pki-tomcat is catalina-`date`.log  It has no errors. The messages match what we see on the functioning replicas.

The error log in /var/log/dirsrv/slapd-DOMAIN-NAME/errors:
Skipping CoS Definition cn=Password Policy,cn=accounts...
set_krb5_creds Could not get initial credentials for principal ldap/server.domain.name in keytab /etc/dirsrv/ds.keytab (Cannot contact any KDC for requested realm)
schema-compat-plugin - tree scan will start in 5 sec
Checking for DES passowrd to convert to AES...
sasl_ldap__sasl_interactive_bind - Error: could not perform interactive bing for id mech Unspecidied GSS failure. No Kerberos credentials available errno 0 (Success)
slapd_ldap_bind - Error: could not perform interative bind for id authentication mechanism error -2

We ran ipa-getkeytab -s ca_server.domain.name -p server.domain.name -k /etc/dirsrv/ds.keytab after the certs were renewed.

# klist -kt /etc/dirsrv/ds.keytab
shows updated timestamp with correct principal
4 11/15/2018 ldap/server.domain.name

Comment 4 Florence Blanc-Renaud 2018-11-16 14:24:48 UTC
Hi,

you can try to start the services with
# ipactl restart --ignore-service-failures

This will let the other services running even if pki tomcat fails to start.
Then I would check that the replication is working (ds.keytab is used to authenticate the replication): verify that the DS keytab is correct and can be used to query other master:

# kinit -kt /etc/dirsrv/ds.keytab ldap/`hostname`
# klist
# ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
# ldapsearch -Y GSSAPI -h the.other.master.fqdn -b "" -s base

Also you mentioned that the master has a CA, but is were the replicas setup with --setup-ca?

Comment 5 GiGi 2018-11-20 14:40:34 UTC
#ipactl restart --ignore-service-failures
  Starting Directory Service
  Failed to read data from Directory Service; unknown error when retrieving     list of services from LDAP (errno 13) Permission Denied.

#kinit admin
  Kinit: Generic error (see e-text) while getting initial credentials

#kinit -kt /etc/dirsrv/ds.keytab ldap/'hostname'
  kinit: Keytab contacts no suitable keys for ldap/'hostname' while getting initial credentials

#klist
klist: Credentials cache keyring 'persistent:1005187:1005187' not found

# ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
ldap_sasl_interactive_bind_s:can't contact LDAP server (-1)


# ldapsearch -Y GSSAPI -h the.other.master.fqdn -b "" -s base
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s:can't contact LDAP server (-2)
additional info: SASL (-1): generic failure:GSSAPI Error: Unspecified GSS failure. Minor Code may provide more info (no Kerberos credentials available)

Comment 6 Florence Blanc-Renaud 2018-11-20 16:07:45 UTC
Hi,
the first error needs to be investigated:
Failed to read data from Directory Service; unknown error when retrieving     list of services from LDAP (errno 13) Permission Denied.

Can you provide the logs from dirsrv corresponding to when 'ipactl restart --ignore-service-failures' is run? On a running system, ipactl first starts the directory service, then connects and performs a search looking for a list of services to start:

(in /var/log/dirsrv/slapd-xxx/access):
[date] conn=8 fd=78 slot=78 connection from local to /var/run/slapd-DOMAIN-COM.socket
[date] conn=8 AUTOBIND dn="cn=Directory Manager"
[date] conn=8 op=0 BIND dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL
[date] conn=8 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0001239907 dn="cn=Directory Manager"
[date] conn=8 op=1 SRCH base="replica.domain.com,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com" scope=2 filter="(ipaConfigString=enabledService)" attrs="ipaConfigString cn"
[date] conn=8 op=1 RESULT err=0 tag=101 nentries=9 etime=0.0003771201 notes=U

We need to find why you get permission denied.
- Did you define a user called root inside IPA or a user with uid=0?
- What is the ldap_uri defined in /etc/ipa/default.conf on this host? Does it start with ldapi://... ?
- What are the permissions for /var/run/slapd-DOMAIN-COM.socket ?

Comment 7 esawtelle 2018-11-27 14:19:17 UTC
The commands were not run correctly last time.  
We re-ran the commands from above.  Here are the results.

# ipactl restart --ignore-service-failures
 Failed to start pki-tomcat
 Force start, ignoring pki-tomcat service, continue normal operation


# kinit admin
#
  success!


# kinit -kt /etc/dirsrv/ds.keytab ldap/'hostname'
# 
  No output is returned just a command prompt


# klist
ticket cache: KEYRING:persistent:0:krbccache
default principal: ldap/`hostname`@REALM
valid               expires             service principal
current date time   current day time    krbtgt REALM@REALM


# ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
  returned the top level of the LDAP schema

# ldapsearch -Y GSSAPI -h the.other.master.fqdn -b "" -s base
  returned the same as the previous command other than the netscapemdsuffix

Comment 8 esawtelle 2018-11-27 14:42:55 UTC
We also ran these commands-

replica# kvno ldap/`hostanme`
ldap/`hostanme` kvno = 4


server# kvno ldap/`hostname`
ldap/`hostname` kvno = 2


server# kinit -kt /etc/dirsrv/ds.keytab ldap/'hostname' 
No output is returned on the server or the replica from this command

Comment 9 esawtelle 2018-11-27 15:20:30 UTC
We changed kinit to klist -

replica# klist -kt /etc/dirsrv/ds.keytab ldap/'hostname'
2 date    time    ldap/`hostname`
4 newdate newtime ldap/`hostname`


server# klist -kt /etc/dirsrv/ds.keytab ldap/'hostname'
2 date    time    ldap/`hostname`

Comment 10 Rob Crittenden 2018-11-27 17:49:21 UTC
You shouldn't have needed to manually update the certificates on the masters. certmonger should do that for you.

What steps did you do to manually import the certs?

Comment 11 esawtelle 2018-11-27 18:56:29 UTC
The RootRA (ipaCert) certificate did not renew automatically.
We used the steps for manually renewing replica certs from:
https://access.redhat.com/solutions/3357331

We exported the following certificates using certutil on the server:
/etc/httpd/alias ipaCert
/etc/pki/pki-tomcat/alias  ocspSigningCert, subsystemCert, auditSigningCert

We imported them using certutil on the replica.

We restarted certmonger and the certificates then showed MONITORING with valid expiration dates.

Comment 12 esawtelle 2018-11-27 21:24:08 UTC
We have noticed the serial number for the ipaCert and the serial number in the uid=ipara,ou=People object keeps getting off.  

2 weeks ago we updated the ldap object to the older serial number (69), which matches all the servers ipaCert.  

It seems the ldap object got updated with a new serial number (268107781) and the usercertificate was added as well but the ipaCert is unchanged.  

Is it better to take the latest certificate from the ldap object and import it on each server using certutil, or just update the serial number in ldap to the older number?

Comment 13 Rob Crittenden 2018-11-27 22:05:35 UTC
You weren't supposed to update all of the certificates. You probably didn't need to touch the agent cert either. You basically circumvented the proper renewal of them.

You are now going to have to manually update some things. See https://www.freeipa.org/page/IPA_2x_Certificate_Renewal and find the part starting "Let's continue getting the CA up and running."

Follow those steps up to "Now you can try to restart the CA to see what happens. It should come up fine" and do the restart. See if that helps.

Comment 14 Petr Čech 2019-02-04 14:31:30 UTC
Hello, could you please provide information if this issue is still valid?


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