Hello,
Were you able to find some useful information from provided pki logs?
Thank you.
On 05/04/2018 10:25 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
I can see lot of warnings but for me most essentials are probably those:
May 04 10:15:35
ipa2.example.com server[31620]: WARNING: Problem with
JAR file [/usr/share/pki/server/common/lib/symkey.jar], exists:
[false], canRead: [false]
May 04 10:15:35
ipa2.example.com server[31620]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'enableOCSP' to 'false' did not find a matching property.
May 04 10:15:35
ipa2.example.com server[31620]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderURL' to 'http://ipa2.example.com:8080/ca/ocsp' did not
find a matching property.
May 04 10:15:35
ipa2.example.com server[31620]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not
find a matching property.
Were does pki get those properties? Is it some config?
Whole log file from restart attached.
Thanks.
With kind regards,
Jan Gardian
On 05/03/2018 09:18 PM, Rob Crittenden wrote:
> Jan Gardian via FreeIPA-users wrote:
>> Hello,
>>
>> Do you have some idea why we get "Certificate Authority not found" ?
>
> IPA proxies requests to the CA through tomcat. Not Found means that
> the CA webapp wasn't running in tomcat. You can try restarting
> pki-tomcatd and seeing what errors are reported in the logs.
>
> rob
>
>>
>> Thanks.
>>
>> With kind regards.
>> Jan Gardian
>>
>> On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
>>> Hello,
>>>
>>> Permission of cert files at ipa2 and ipa3 are ok. I was installing
>>> replica under admin user. Master CA should be setup but it still
>>> crash with CA not found. I was still able to create ipa2 and ipa3
>>> replica with old ipa1(ubuntu 16) server without problem.
>>> Bellow are also error_logs from httpd and certmonger. Any idea what
>>> else I can check? Our ipa CA is signed by our own CA, could this
>>> cause some problems?
>>>
>>> [root@ipa4 ~]# klist -kt /etc/krb5.keytab
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Timestamp Principal
>>> ---- -------------------
>>> ------------------------------------------------------
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> 1 04/26/2018 10:21:04 host/ipa4.example.com(a)EXAMPLE.COM
>>> [root@ipa4 ~]# kvno host/`hostname`
>>> host/ipa4.example.com(a)EXAMPLE.COM: kvno = 1
>>>
>>> ipa-replica-install --setup-ca fails at the same point:
>>> Configuring directory server (dirsrv)
>>> [1/3]: configuring TLS for DS instance
>>> [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
>>> ERROR Certificate issuance failed (CA_UNREACHABLE)
>>> ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
>>> ERROR The ipa-replica-install command failed. See
>>> /var/log/ipareplica-install.log for more information
>>>
>>> Master CA setup to be ipa2:
>>> [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates
>>> /etc/pki/pki-tomcat/ca/CS.cfg
>>> ca.crl.MasterCRL.enableCRLUpdates=true
>>>
>>> [root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates
>>> /etc/pki/pki-tomcat/ca/CS.cfg
>>> ca.crl.MasterCRL.enableCRLUpdates=false
>>>
>>> ipa4 certmonger logs:
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Certificate submission still ongoing.
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic
>>> from 15.
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Certificate submission attempt complete.
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Child status = 3.
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Child output:
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: "Server at
>>>
https://ipa4.example.com/ipa/xml failed request, will retry: -504
>>> (libcurl failed to execute the HTTP POST transaction, explaining:
>>> Failed connect to ipa4.example.com:443; Connection ref
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: Server at
>>>
https://ipa3.example.com/ipa/xml failed request, will retry: 4001
>>> (RPC failed at server. ipa: Certificate Authority not found).
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: Server at
>>>
https://ipa2.example.com/ipa/xml failed request, will retry: 4001
>>> (RPC failed at server. ipa: Certificate Authority not found).
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: "
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Certificate not (yet?) issued.
>>> Apr 26 10:27:38
ipa4.example.com certmonger[1713]: 2018-04-26
>>> 10:27:38 [1713] Request1('20180426082737') moved to state
>>> 'CA_UNREACHABLE'
>>>
>>> ipa3 httpd/error_log:
>>> [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724]
>>> [client 1.1.1.4:35234] NO AUTH DATA Client did not send any
>>> authentication headers, referer:
https://ipa3.example.com/ipa/xml
>>> [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO:
>>> [xmlserver] host/ipa4.example.com(a)EXAMPLE.COM:
>>> cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert',
>>> principal=u'ldap/ipa4.example.com(a)EXAMPLE.COM', add=True,
>>> version=u'2.51'): NotFound
>>>
>>> [root@ipa3 ~]# ipa ca-show ipa
>>> ipa: ERROR: ipa: Certificate Authority not found
>>>
>>>
>>>
>>> ipa2 httpd/error_log:
>>> [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO:
>>> [jsonserver_kerb] admin(a)EXAMPLE.COM:
>>> server_conncheck(u'ipa2.example.com', u'ipa4.example.com',
>>> version=u'2.162'): SUCCESS
>>> [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336]
>>> [client 1.1.1.4:59674] NO AUTH DATA Client did not send any
>>> authentication headers, referer:
https://ipa2.example.com/ipa/xml
>>> [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO:
>>> [xmlserver] host/ipa4.example.com(a)EXAMPLE.COM:
>>> cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert',
>>> principal=u'ldap/ipa4.example.com(a)EXAMPLE.COM', add=True,
>>> version=u'2.51'): NotFound
>>>
>>> [root@ipa2 ~]# ipa ca-show ipa
>>> ipa: ERROR: ipa: Certificate Authority not found
>>>
>>>
>>> With kind regards,
>>> Jan Gardian
>>>
>>> On 04/24/2018 02:52 PM, Rob Crittenden wrote:
>>>> Jan Gardian via FreeIPA-users wrote:
>>>>> Hello,
>>>>>
>>>>> I setup more verbose output for certmonger and tested to install ipa
>>>>> replica at ipa4. What credentials does certmonger use? Installing
>>>>> replica is run with admin credentials.
>>>> certmonger uses the host principal in /etc/krb5.keytab
>>>>
>>>> I'd check on the remote servers /var/log/httpd/error_log to see if
>>>> anything was logged for the cert requests. Invalid credentials seems
>>>> like an odd error.
>>>>
>>>> You can also check on the validity of the keytab with:
>>>>
>>>> # klist -kt /etc/krb5.keytab
>>>> # kvno host/`hostname`
>>>>
>>>> The kvno should match.
>>>>
>>>> IIRC you are promoting a client to a replica which means there
>>>> shouldn't
>>>> be any issues with replication of the host principal.
>>>>
>>>> rob
>>>>
>>>>> Servers ipa2 and ipa3 are up.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Certificate submission still ongoing.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Will revisit Request1('20180424112419') on traffic
from 15.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Certificate submission attempt complete.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Child status = 2.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Child output:
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: "Server at
>>>>>
https://ipa4.example.com/ipa/xml failed request, will retry: -504
>>>>> (libcurl failed to execute the HTTP POST transaction, explaining:
>>>>> Failed
>>>>> connect to ipa4.example.com:443; Connection refused).
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: Server at
>>>>>
https://ipa3.example.com/ipa/xml denied our request, giving up: 2100
>>>>> (RPC failed at server. Insufficient access: Invalid credentials).
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: "
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Certificate not (yet?) issued.
>>>>> Apr 24 13:24:19
ipa4.example.com certmonger[1755]: 2018-04-24
>>>>> 13:24:19
>>>>> [1755] Request1('20180424112419') moved to state
>>>>> 'NEED_TO_NOTIFY_REJECTION'
>>>>>
>>>>>
>>>>> Only ipa2 is up
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Certificate submission still ongoing.
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Will revisit Request1('20180424115242') on traffic
from 15.
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Certificate submission attempt complete.
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Child status = 3.
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Child output:
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: "Server at
>>>>>
https://ipa4.example.com/ipa/xml failed request, will retry: -504
>>>>> (libcurl failed to execute the HTTP POST transaction, explaining:
>>>>> Failed
>>>>> connect to ipa4.example.com:443; Connection refused).
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: Server at
>>>>>
https://ipa3.example.com/ipa/xml failed request, will retry: -504
>>>>> (libcurl failed to execute the HTTP POST transaction, explaining:
>>>>> Failed
>>>>> connect to ipa3.example.com:443; No route to host).
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: Server at
>>>>>
https://ipa2.example.com/ipa/xml failed request, will retry: 4001
>>>>> (RPC
>>>>> failed at server. ipa: Certificate Authority not found).
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: "
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Certificate not (yet?) issued.
>>>>> Apr 24 13:52:46
ipa4.example.com certmonger[1715]: 2018-04-24
>>>>> 13:52:46
>>>>> [1715] Request1('20180424115242') moved to state
'CA_UNREACHABLE'
>>>>>
>>>>>
>>>>> With kind regards,
>>>>> Jan Gardian
>>>>>
>>>>> On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I checked and we already have correct permission for mentioned
cert
>>>>>> files:
>>>>>>
>>>>>> [root@ipa2 ~]# ls -la /etc/ipa/ca.crt
>>>>>> -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt
>>>>>> [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.*
>>>>>> -r--r-----. 1 root ipaapi 1854 Apr 18 09:50
>>>>>> /var/lib/ipa/ra-agent.key
>>>>>> -r--r-----. 1 root ipaapi 1423 Apr 18 09:50
>>>>>> /var/lib/ipa/ra-agent.pem
>>>>>>
>>>>>> And when doing replica install at ipa4 it still tries to get
>>>>>> certificate from itself and not from master ipa2:
>>>>>> [root@ipa4 ~]# getcert list
>>>>>> Number of certificates and requests being tracked: 1.
>>>>>> Request ID '20180424101635':
>>>>>> status: CA_REJECTED
>>>>>> ca-error: Server at
https://ipa4.example.com/ipa/xml failed
>>>>>> request, will retry: -504 (libcurl failed to execute the HTTP
POST
>>>>>> transaction, explaining: Failed connect to
ipa4.example.com:443;
>>>>>> Connection refused).
>>>>>> stuck: yes
>>>>>> key pair storage:
>>>>>>
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
>>>>>>
>>>>>> Certificate
DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt'
>>>>>> certificate:
>>>>>>
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
>>>>>>
>>>>>>
>>>>>> CA: IPA
>>>>>> issuer:
>>>>>> subject:
>>>>>> expires: unknown
>>>>>> pre-save command:
>>>>>> post-save command:
/usr/libexec/ipa/certmonger/restart_dirsrv
>>>>>> EXAMPLE-COM
>>>>>> track: yes
>>>>>> auto-renew: yes
>>>>>>
>>>>>>
>>>>>>
>>>>>> With kind regards,
>>>>>> Jan Gardian
>>>>>>
>>>>>>
>>>>>> On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
>>>>>>> On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users
wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> I got this same error with replica installation on rhel
7.4 after
>>>>>>>> the OS was hardened with openscap. Pure base OS install
>>>>>>>> without any
>>>>>>>> additional hardening did work without problems. I was
doing
>>>>>>>> replica
>>>>>>>> immediately after setting up the new primary.
>>>>>>>>
>>>>>>>> Also, with same scap policy the fresh primary ipa did not
>>>>>>>> allow any
>>>>>>>> login at webui. In my case I believe it was about some
security
>>>>>>>> setting but have not yet had time to debug which one.
Dunno
>>>>>>>> where to
>>>>>>>> start the debug though.
>>>>>>>>
>>>>>>>> br,
>>>>>>>> risto
>>>>>>>>
>>>>>>>> Sent from my iPad
>>>>>>>>
>>>>>>>> On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users
>>>>>>>> <freeipa-users(a)lists.fedorahosted.org
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>>
wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> We had two ipa replicas ipa1 with CA and ipa2. Those
servers
>>>>>>>>> were
>>>>>>>>> on Ubuntu 16.
>>>>>>>>>
>>>>>>>>> I successfully installed ipa3 replica with CA that is
running on
>>>>>>>>> newer version of IPA and Centos 7. After that I
stopped old ipa2
>>>>>>>>> and successfully installed new ipa2 with CA on Centos
7.
>>>>>>>>> Lastly I
>>>>>>>>> setup CA master to be new ipa2 following
>>>>>>>>>
https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#P...
>>>>>>>>>
>>>>>>>>> and turned off old ipa1 server.
>>>>>>>>>
>>>>>>>>> Problem occurred when I was installing replica with
CA to new
>>>>>>>>> ipa1
>>>>>>>>> server running at Centos 7.
>>>>>>>>> I can successfully install ipa client and create
ticket under
>>>>>>>>> admin
>>>>>>>>> user but when trying to install replica it fails with
"ERROR
>>>>>>>>> Certificate issuance failed (CA_UNREACHABLE)".
Somehow it
>>>>>>>>> tries to
>>>>>>>>> get certificates during replica install from ipa1
server when it
>>>>>>>>> does not have yet httpd installed.
>>>>>>>>>
>>>>>>>>> I thought it could be problem that certificate was
primary
>>>>>>>>> created
>>>>>>>>> at old ipa1 and we have it signed by our own
certificates as
>>>>>>>>> well
>>>>>>>>> so I created another ipa4 server on Centos 7. And
again it
>>>>>>>>> crashed
>>>>>>>>> at the same point trying to get certificate from
itself when
>>>>>>>>> it did
>>>>>>>>> not have httpd installed yet.
>>>>>>>>>
>>>>>>>>> OS: CentOS Linux release 7.4.1708
>>>>>>>>> IPA: VERSION: 4.5.0, API_VERSION: 2.228
>>>>>>>>>
>>>>>>>>> Attached are logs from ipa client installation and
ipa replica
>>>>>>>>> installation for ipa4 server.
>>>>>>>>> Please ask if you require any different logs. I tried
also to
>>>>>>>>> follow debugging from
>>>>>>>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>>>>>
>>>>>>>>> but in my case it end earlier because it try to get
certificate
>>>>>>>>> from itself and does not get to master. This can be
also seen in
>>>>>>>>> output of command getcert list(in attachement).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you for checking.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With kind regards,
>>>>>>>>> *Ján Gardian*
>>>>>>>>> Administrator
>>>>>>>>> <ipa4_debug>
>>>>>>>>> _______________________________________________
>>>>>>>>> FreeIPA-users mailing list --
>>>>>>>>> freeipa-users(a)lists.fedorahosted.org
>>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>>> To unsubscribe send an email to
>>>>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>>>
<mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> FreeIPA-users mailing list --
>>>>>>>> freeipa-users(a)lists.fedorahosted.org
>>>>>>>> To unsubscribe send an email to
>>>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> the issue is probably linked to the root's umask setting
on the
>>>>>>> master. When umask is too restrictive, the httpd server is
not
>>>>>>> able
>>>>>>> to read the CA file and establish a secure connection with
Dogtag.
>>>>>>> This is a known issue [1], the workaround is to modify the
cert
>>>>>>> file
>>>>>>> permissions:
>>>>>>> chmod 644 /etc/ipa/ca.crt
>>>>>>> chmod 440 /var/lib/ipa/ra-agent.{key|pem}
>>>>>>>
>>>>>>> HTH,
>>>>>>> Flo
>>>>>>>
>>>>>>> [1]
https://pagure.io/freeipa/issue/7193
>>>>>> _______________________________________________
>>>>>> FreeIPA-users mailing list --
freeipa-users(a)lists.fedorahosted.org
>>>>>> To unsubscribe send an email to
>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>> _______________________________________________
>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>> To unsubscribe send an email to
>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
--
*Ján Gardian*
Administrator
+420 511 140 900
*CYAN Research & Development s.r.o.*
Palackého třída 879/84, 612 00 Brno, CZ
Upozornění: Tento e-mail včetně všech příloh je důvěrný a může být
předmětem obchodního tajemství. Pokud nejste zamýšleným adresátem,
upozorněte prosím ihned odesilatele, zničte všechny kopie z Vašeho
systému a nevyzrazujte nebo nepoužívejte tyto informace k žádnému účelu.
Notice: This e-mail and any attachments are confidential and may be
privileged. If you are not the intended recipient, notify the sender
immediately, destroy all copies from your system and do not disclose or
use the information for any purpose.