[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 01/10/2018 10:06 AM, Harald Dunkel via FreeIPA-users wrote: On 12/14/17 17:09, Harald Dunkel via FreeIPA-users wrote: Hi Flo, Rob, On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote: The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug. You are right, its a set of certificates. Maybe a related problem: ldapmodify gives me % ldapmodify -ZZ -D "cn=directory manager" -W -a ldap_start_tls: Operations error (1) additional info: SSL connection already established. Hi, with -ZZ ldapsearch will be using startTLS and the error means that it's trying to establish a startTLS session over an ssl connection. This probably happens because the /etc/openldap/ldap.conf (or ldaprc, .ldaprc) defines URI ldaps://hostname Can you try with ldap instead of ldaps: ldapmodify -ZZ -D "cn=directory manager" -W -H ldap://`hostname` HTH, Flo ??? Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo, Rob, On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote: The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug. You are right, its a set of certificates. One last question: Is it safe to drop the old root CA from the certutil database? Its no longer in LDAP, anyway. "getcert list" doesn't mention any certificates derived from the old PKI, either. I highly appreciate your support and patience Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/13/2017 04:39 PM, Harald Dunkel via FreeIPA-users wrote: Hi Flo, On 12/12/17 3:59 PM, Harald Dunkel via FreeIPA-users wrote: My concern is, it looks much more restricted than the old root CA cerificate: # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, Shouldn't it be "CT,C,C" as well? : : Hi, the flags here will be the same as the ones used with the command ipa-cacert-manage install -t . If I recall correctly, in most cases you need only C,, but if your deployment requires more flags (for instance the external CA is used to sign Smart Card certificates), you can tune this by providing the required flags in ipa-cacert-manage install. ipa-cert-update said # ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful dmesg shows that there was a core dump: [108604.869633] ns-slapd[23051]: segfault at 10 ip 7fb60841dc30 sp 7fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000] Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate. AFAICT this is not as documented. Would you suggest to file a bug report? The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug. Flo Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo, On 12/12/17 3:59 PM, Harald Dunkel via FreeIPA-users wrote: My concern is, it looks much more restricted than the old root CA cerificate: # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, Shouldn't it be "CT,C,C" as well? : : ipa-cert-update said # ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful dmesg shows that there was a core dump: [108604.869633] ns-slapd[23051]: segfault at 10 ip 7fb60841dc30 sp 7fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000] Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate. AFAICT this is not as documented. Would you suggest to file a bug report? Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo, On 12/12/17 2:50 PM, Florence Blanc-Renaud via FreeIPA-users wrote: On 12/10/2017 10:58 AM, Harald Dunkel via FreeIPA-users wrote: Hi Flo, On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote: Hi, I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes. Flo Result: The new root CA certificate shows much better attributes in ldap: dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ipaPublicKey:: MIICIjAN... cACertificate;binary:: MIIGDTCC... ipaKeyTrust: trusted ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE;1 A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the old root CA certificate. Is this expected? The ipaKeyExtUsage attribute is built from the trust flags provided to ipa-cacert-manage install, so it looks normal for me. My concern is, it looks much more restricted than the old root CA cerificate: # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-cau,u,u caSigningCert cert-pki-caCTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, Shouldn't it be "CT,C,C" as well? ipa-certupdate needs to be run with a kerberos ticket. Did you run kinit admin before launching the command, and is your ticket still valid (klist will provide the expiration date)? Nope, that was the problem. I was just looking for the certificate, ignoring Kerberos. ipa-cert-update said # ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful dmesg shows that there was a core dump: [108604.869633] ns-slapd[23051]: segfault at 10 ip 7fb60841dc30 sp 7fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000] Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate. Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/10/2017 10:58 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo,
On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
I would try to remove the new root CA from LDAP and re-import it using
ipa-cacert-manage install -t C,,
This should create the entry with the appropriate attributes.
Flo
Result: The new root CA certificate shows much better attributes in ldap:
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGDTCC...
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example
AG,C=DE;1
A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the
old root CA certificate. Is this expected?
The ipaKeyExtUsage attribute is built from the trust flags provided to
ipa-cacert-manage install, so it looks normal for me.
ipa-certupdate failed:
# ipa-certupdate -v
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file
ipa: DEBUG: Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: trying
https://ipa1.example.de/ipa/json
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Created connection
context.rpcclient_54790992
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: [try 1]: Forwarding 'schema'
to json server 'https://ipa1.example.de/ipa/json'
ipa: DEBUG: New HTTP connection (ipa1.example.de)
ipa: DEBUG: HTTP connection destroyed (ipa1.example.de)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in
single_request
self.get_auth_info()
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in
get_auth_info
self._handle_exception(e, service=service)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in
_handle_exception
raise errors.TicketExpired()
TicketExpired: Ticket expired
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection
context.rpcclient_54790992
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_certupdate.py",
line 57, in run
api.finalize()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in
finalize
self.__do_if_not_done('load_plugins')
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in
__do_if_not_done
getattr(self, name)()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in
load_plugins
for package in self.packages:
File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in
packages
ipaclient.remote_plugins.get_package(self),
File
"/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line
126, in get_package
plugins = schema.get_package(server_info, client)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 534, in get_package
schema = Schema(client)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 385, in __init__
fingerprint, ttl = self._fetch(client, ignore_cache=read_failed)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 409, in _fetch
schema = client.forward(u'schema', **kwargs)['result']
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1116, in forward
return self._call_command(command, params)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1092, in
_call_command
return command(*params)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call
return self.__request(name, args)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in
__request
verbose=self.__verbose >= 3,
File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in
single_request
self.get_auth_info()
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in
get_auth_info
self._handle_exception(e, service=service)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in
_handle_exception
raise errors.TicketExpired()
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: The ipa-certupdate
command failed, exception: TicketExpired: Ticket expired
ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: Ticket
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi folks, any ideas about how to proceed? Is this bbr? Do I have to reactivate the old pki to get out of this mess? Every helpful comment is highly appreciated. Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo,
On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
> Hi,
>
> I would try to remove the new root CA from LDAP and re-import it using
> ipa-cacert-manage install -t C,,
> This should create the entry with the appropriate attributes.
>
> Flo
Result: The new root CA certificate shows much better attributes in ldap:
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGDTCC...
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example
AG,C=DE;1
A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the
old root CA certificate. Is this expected?
ipa-certupdate failed:
# ipa-certupdate -v
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file
ipa: DEBUG: Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: trying
https://ipa1.example.de/ipa/json
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Created connection
context.rpcclient_54790992
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: [try 1]: Forwarding 'schema'
to json server 'https://ipa1.example.de/ipa/json'
ipa: DEBUG: New HTTP connection (ipa1.example.de)
ipa: DEBUG: HTTP connection destroyed (ipa1.example.de)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in
single_request
self.get_auth_info()
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in
get_auth_info
self._handle_exception(e, service=service)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in
_handle_exception
raise errors.TicketExpired()
TicketExpired: Ticket expired
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection
context.rpcclient_54790992
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_certupdate.py",
line 57, in run
api.finalize()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in
finalize
self.__do_if_not_done('load_plugins')
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in
__do_if_not_done
getattr(self, name)()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in
load_plugins
for package in self.packages:
File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in
packages
ipaclient.remote_plugins.get_package(self),
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py",
line 126, in get_package
plugins = schema.get_package(server_info, client)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 534, in get_package
schema = Schema(client)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 385, in __init__
fingerprint, ttl = self._fetch(client, ignore_cache=read_failed)
File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py",
line 409, in _fetch
schema = client.forward(u'schema', **kwargs)['result']
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1116, in forward
return self._call_command(command, params)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1092, in
_call_command
return command(*params)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call
return self.__request(name, args)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request
verbose=self.__verbose >= 3,
File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in
single_request
self.get_auth_info()
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in
get_auth_info
self._handle_exception(e, service=service)
File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in
_handle_exception
raise errors.TicketExpired()
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: The ipa-certupdate
command failed, exception: TicketExpired: Ticket expired
ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: Ticket expired
ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: The ipa-certupdate
command failed.
Restarting ipa did not help. ???
Regards
Harri
signature.asc
Description: OpenPGP digital signature
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/08/2017 01:08 PM, Harald Dunkel via FreeIPA-users wrote: Hi Flo, On 12/8/17 10:52 AM, Florence Blanc-Renaud wrote: Hi Harald, the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install. ACK You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt. The ipa Servers ipa1 and ipa2 are in sync, as reported by ipa-replica-manage and ipa-csreplica-manage. jxplorer shows me 3 certificates: - the ipa ca certificate signed by the new root CA - the old root CA certificate "cn=example Root CA, ..." - the new root CA certificate "cn=root-CA, ..." The old root CA certificate has much more attributes set than the new one, esp. there is an attribute ipaKeyTrust set to "trusted", and several other ipaKeyExtUsage attributes not set for the new root CA certificate. Attached you can find the output of ldapsearch for cn=certificates. As you suggested, I used ipa-certupdate to deploy the new PKI, but I wonder if the attributes for the new root CA certificate are set correctly? Please note the "ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16" set only for the new root CA cert. Looking into the old and new root CA certs I see very similar x509v3 extensions. Do you think the new root certificate could be bad internally? If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent. I highly appreciate this central location. If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate. AFAIU it is necessary to fix the attributes of the new root CA certificate entry in LDAP first. Would you recommend to set the lost ipaKeyExtUsage attributes? Hi, I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes. Flo Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo, On 12/8/17 10:52 AM, Florence Blanc-Renaud wrote: Hi Harald, the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install. ACK You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt. The ipa Servers ipa1 and ipa2 are in sync, as reported by ipa-replica-manage and ipa-csreplica-manage. jxplorer shows me 3 certificates: - the ipa ca certificate signed by the new root CA - the old root CA certificate "cn=example Root CA, ..." - the new root CA certificate "cn=root-CA, ..." The old root CA certificate has much more attributes set than the new one, esp. there is an attribute ipaKeyTrust set to "trusted", and several other ipaKeyExtUsage attributes not set for the new root CA certificate. Attached you can find the output of ldapsearch for cn=certificates. As you suggested, I used ipa-certupdate to deploy the new PKI, but I wonder if the attributes for the new root CA certificate are set correctly? Please note the "ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16" set only for the new root CA cert. Looking into the old and new root CA certs I see very similar x509v3 extensions. Do you think the new root certificate could be bad internally? If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent. I highly appreciate this central location. If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate. AFAIU it is necessary to fix the attributes of the new root CA certificate entry in LDAP first. Would you recommend to set the lost ipaKeyExtUsage attributes? Regards Harri # extended LDIF # # LDAPv3 # base
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/08/2017 08:01 AM, Harald Dunkel via FreeIPA-users wrote: Hi Flo and Andrew, thanx for you replies, but I think you missed the point: The new (external) root CA certificate and the new ipa CA certificate are *in* freeipa already, but on the host I had used for running ipa-cacert-manage to deploy this new PKI the database in /var/lib/pki/pki-tomcat/ca/alias appears to be in an inconsistent state. Manually fixing this is not persistent. If I create another CA replica, then this server looks fine, except for the old root CA still in /etc/ipa/ca.crt . I would like to get rid of the old PKI completely. Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Hi Harald, the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install. You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt. If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent. If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate. Hope this clarifies, Flo. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Flo and Andrew, thanx for you replies, but I think you missed the point: The new (external) root CA certificate and the new ipa CA certificate are *in* freeipa already, but on the host I had used for running ipa-cacert-manage to deploy this new PKI the database in /var/lib/pki/pki-tomcat/ca/alias appears to be in an inconsistent state. Manually fixing this is not persistent. If I create another CA replica, then this server looks fine, except for the old root CA still in /etc/ipa/ca.crt . I would like to get rid of the old PKI completely. Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Harald, Maybe in the ldap certificate container you already have the same certificate you're trying to install, but it has another key or untrusted? Then try to delete it via ldapdelete and certutil -d and then try again install new one. 2017-12-07 17:20 GMT+03:00 Harald Dunkel via FreeIPA-users < freeipa-users@lists.fedorahosted.org>: > On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote: > >> >> Hi, >> >> if you run: >> >> ipa-cacert-manage install -t C,, >> ipa-certupdate >> >> then the new root certificate will be installed in all the required NSS >> databases. Do not forget to run ipa-certupdate on all the FreeIPA machines. >> >> > This did not work: > > [root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > The ipa-cacert-manage command failed. > > > > > Regards > Harri > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > -- Best regards, Andrew. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote: Hi, if you run: ipa-cacert-manage install -t C,, ipa-certupdate then the new root certificate will be installed in all the required NSS databases. Do not forget to run ipa-certupdate on all the FreeIPA machines. This did not work: [root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt Installing CA certificate, please wait Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. (visit http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) The ipa-cacert-manage command failed. Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
On 12/07/2017 09:17 AM, Harald Dunkel via FreeIPA-users wrote: Hi Rob, On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote: Harald Dunkel via FreeIPA-users wrote: Here is what I see on the broken ipa server: [root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,, The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago. The certificate database on another ipa server (not broken yet, as it seems) looks different: [root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u I would highly appreciate any advice how to cleanup this mess. How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap. What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start. The first ipa server was setup using an existing private PKI, managed outside of freeipa. The root ca cert had a problem I noticed too late: It uses an invalid format for the notAfter attribute. openssl is fine with this format, but libressl on OpenBSD (and probably MacOS) rejects it. See this thread for more information: https://marc.info/?l=libressl=148939571912276=2 Point is, I had to create a new private PKI with a valid notAfter attribute format, and to tell freeipa. I had used ipa-cacert-manage to fix, following the guidelines on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext ipa-cacert-manage renew --external-ca : ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem --external-cert-file=/tmp/cacert.pem ipa-certupdate : getcert list getcert list | egrep Request\|CA\|issuer\|subject\|expires : ipa-getcert resubmit -i $request_id : So how comes that the new root certificate is not trusted? Hi, if you run: ipa-cacert-manage install -t C,, ipa-certupdate then the new root certificate will be installed in all the required NSS databases. Do not forget to run ipa-certupdate on all the FreeIPA machines. HTH, Flo. To fix this you could run: # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,, Done. ipa1 starts again. But this is not sufficient. If I run ipa-certupdate, then the database is set back to the bad state. /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too. ??? Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
PS: I have derived another CA replica "ipa0" from ipa2. certutil shows different trustargs again. Shouldn't ipa2 and the new ipa0 have identical trustargs? [root@ipa0 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu subsystemCert cert-pki-cau,u,u Server-Cert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-caCTu,Cu,Cu ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ipa2 has: [root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu subsystemCert cert-pki-cau,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-caCTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Rob, On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote: Harald Dunkel via FreeIPA-users wrote: Here is what I see on the broken ipa server: [root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-cau,u,u caSigningCert cert-pki-caCTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,, The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago. The certificate database on another ipa server (not broken yet, as it seems) looks different: [root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu subsystemCert cert-pki-cau,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-caCTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u I would highly appreciate any advice how to cleanup this mess. How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap. What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start. The first ipa server was setup using an existing private PKI, managed outside of freeipa. The root ca cert had a problem I noticed too late: It uses an invalid format for the notAfter attribute. openssl is fine with this format, but libressl on OpenBSD (and probably MacOS) rejects it. See this thread for more information: https://marc.info/?l=libressl=148939571912276=2 Point is, I had to create a new private PKI with a valid notAfter attribute format, and to tell freeipa. I had used ipa-cacert-manage to fix, following the guidelines on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext ipa-cacert-manage renew --external-ca : ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem --external-cert-file=/tmp/cacert.pem ipa-certupdate : getcert list getcert list | egrep Request\|CA\|issuer\|subject\|expires : ipa-getcert resubmit -i $request_id : So how comes that the new root certificate is not trusted? To fix this you could run: # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,, Done. ipa1 starts again. But this is not sufficient. If I run ipa-certupdate, then the database is set back to the bad state. /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too. ??? Regards Harri ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Harald Dunkel via FreeIPA-users wrote: > Hi Rob, > > On 12/06/17 17:39, Rob Crittenden via FreeIPA-users wrote: >> Harald Dunkel via FreeIPA-users wrote: >>> See attachment. >>> >>> Please note the "invalid certificate". Du you remember the thread >>> on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails >>> after root certificate change via ipa-cacert-manage" and the >>> output of "ipa-certupdate -v" I had posted? >>> >> >> The ipa-certupdate error was a red herring. IPA was just looking for all >> possible CA certs it could know about. >> > OK. > >> It does look like the trust is wrong on your CA cert in the tomcat NSS >> database. >> >> # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias >> [ snip ] >> caSigningCert cert-pki-caCTu,Cu,Cu >> >> If yours isn't that > > Sorry, but I don't understand. My what isn't what? If your entry doesn't look like that, which it does. >> you can try modifying it with: >> >> # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert >> cert-pki-ca" -t CTu,Cu,Cu >> > Here is what I see on the broken ipa server: > > > [root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert cert-pki-ca u,u,u > subsystemCert cert-pki-cau,u,u > caSigningCert cert-pki-caCTu,Cu,Cu > auditSigningCert cert-pki-ca u,u,Pu > ocspSigningCert cert-pki-ca u,u,u > CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C > CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,, > > > The CN=example Root CA,... certificate is unwanted. It did not expire, > but it uses an invalid format for its expiration date. I ran ipa-cacert-manage > to replace it with the CN=root-CA,... certificate a few months ago. > > > The certificate database on another ipa server (not broken yet, as it > seems) looks different: > > > [root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > caSigningCert cert-pki-caCTu,Cu,Cu > subsystemCert cert-pki-cau,u,u > CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C > caSigningCert cert-pki-caCTu,Cu,Cu > CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, > ocspSigningCert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > Server-Cert cert-pki-ca u,u,u > > > I would highly appreciate any advice how to cleanup this mess. > > How comes that the unwanted "example Root CA" is still in the databases at > all? Due to the broken format I have to get rid of it asap. What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start. To fix this you could run: # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,, rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Hi Rob, On 12/06/17 17:39, Rob Crittenden via FreeIPA-users wrote: > Harald Dunkel via FreeIPA-users wrote: >> See attachment. >> >> Please note the "invalid certificate". Du you remember the thread >> on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails >> after root certificate change via ipa-cacert-manage" and the >> output of "ipa-certupdate -v" I had posted? >> > > The ipa-certupdate error was a red herring. IPA was just looking for all > possible CA certs it could know about. > OK. > It does look like the trust is wrong on your CA cert in the tomcat NSS > database. > > # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias > [ snip ] > caSigningCert cert-pki-caCTu,Cu,Cu > > If yours isn't that Sorry, but I don't understand. My what isn't what? > you can try modifying it with: > > # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert > cert-pki-ca" -t CTu,Cu,Cu > Here is what I see on the broken ipa server: [root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-cau,u,u caSigningCert cert-pki-caCTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,, The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago. The certificate database on another ipa server (not broken yet, as it seems) looks different: [root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu subsystemCert cert-pki-cau,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-caCTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u I would highly appreciate any advice how to cleanup this mess. How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap. Regards Harri signature.asc Description: OpenPGP digital signature ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Harald Dunkel via FreeIPA-users wrote: > See attachment. > > Please note the "invalid certificate". Du you remember the thread > on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails > after root certificate change via ipa-cacert-manage" and the > output of "ipa-certupdate -v" I had posted? > The ipa-certupdate error was a red herring. IPA was just looking for all possible CA certs it could know about. It does look like the trust is wrong on your CA cert in the tomcat NSS database. # certutil -L -d /var/lib/pki/pki-tomcat/ca/alias [ snip ] caSigningCert cert-pki-caCTu,Cu,Cu If yours isn't that you can try modifying it with: # certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert cert-pki-ca" -t CTu,Cu,Cu rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
See attachment. Please note the "invalid certificate". Du you remember the thread on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage" and the output of "ipa-certupdate -v" I had posted? Regards Harri debug.txt.gz Description: application/gzip ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore
Harald Dunkel via FreeIPA-users wrote: > Hi folks, > > Platform: Centos 7.4, ipa 4.5.0-21 > > The ipa service cannot be started anymore. Error message: > > # systemctl status ipa > * ipa.service - Identity, Policy, Audit >Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; vendor > preset: disabled) >Active: failed (Result: exit-code) since Wed 2017-12-06 14:45:53 CET; > 12min ago > Process: 307 ExecStart=/usr/sbin/ipactl start (code=exited, > status=1/FAILURE) > Main PID: 307 (code=exited, status=1/FAILURE) > > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting Directory Service > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting krb5kdc Service > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting kadmin Service > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting httpd Service > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting ipa-custodia Service > Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting pki-tomcatd Service > Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service: main process > exited, code=exited, status=1/FAILURE > Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Failed to start Identity, > Policy, Audit. > Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Unit ipa.service entered > failed state. > Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service failed. > > > Apparently pki-tomcatd is to blame. See the attached logfiles. Need the (compressed) debug log. You can get the rest of the IPA service started by passing --ignore-service-failures to ipactl. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
