Anvar Kuchkartaev wrote:
> Peer certificate cannot be authenticated with known CA certificates
> This error shows that your system cannot authenticate remote host (curl
> probably trying to authenticate using systemwide database rather than
> the CA certificate obtained from server). Try to add CA to the CA
> database of operating system on client.
> 
> In redhat based linux:
> Add ca.crt file to folder:
> /etc/pki/ca-trust/source/anchors
> And‎ execute:
> update-ca-trust extract
> 
> On debian:
> https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/

As I said, this will be done automatically by ipa-client-install. The
one in LDAP does not match the one that signed the web cert, though I
assume it is the same private key so things are a bit odd.

rob

> 
> 
> Anvar Kuchkartaev 
> an...@aegisnet.eu 
> *From: *Bhavin Vaidya
> *Sent: *lunes, 23 de octubre de 2017 08:07 p.m.
> *To: *Anvar Kuchkartaev; Bhavin Vaidya via FreeIPA-users; Rob
> Crittenden; Bhavin Vaidya via FreeIPA-users
> *Cc: *John Dennis
> *Subject: *Re: [Freeipa-users] Re: several IPA CA certificate entries
> 
> 
> Thank you Anvar.
> 
> 
> Yes earlier when we had certificate issue, we added new certificates and
> we ended up having multiple certificates. Which we had to clean up.
> 
> Is this the question you asked?
> 
> 
> after deleting extras certificates,  we have not touch /etc/pki/nssdb.
> 
> 
> regards,
> 
> Bhavin
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* Anvar Kuchkartaev <an...@aegisnet.eu>
> *Sent:* Monday, October 23, 2017 10:53 AM
> *To:* Bhavin Vaidya via FreeIPA-users; Rob Crittenden; FreeIPA users list
> *Cc:* John Dennis; Bhavin Vaidya
> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
>  
> Have you tried to add CA to systemwide database?
> 
> Anvar Kuchkartaev 
> an...@aegisnet.eu 
> *From: *Bhavin Vaidya via FreeIPA-users
> *Sent: *lunes, 23 de octubre de 2017 07:46 p.m.
> *To: *Rob Crittenden; FreeIPA users list
> *Reply To: *FreeIPA users list
> *Cc: *John Dennis; Bhavin Vaidya
> *Subject: *[Freeipa-users] Re: several IPA CA certificate entries
> 
> 
> Thank you everyone.
> 
> 
> We did manage to delete the certificates, all but the right one (we
> figured out looking at clients' /etc/ipa/ca.crt)
> 
> 
> But on client installation we now get different message, which is
> related to certificate too. tried another IPA server too, same message.
> 
> 
> Successfully retrieved CA cert
>     Subject:     CN=Certificate Authority,O=EXAMPLE.COM
>     Issuer:      CN=Certificate Authority,O=EXAMPLE.COM
>     Valid From:  Thu Jun 01 12:55:08 2017 UTC
>     Valid Until: Mon Jun 01 12:55:08 2037 UTC
> 
> Joining realm failed: libcurl failed to execute the HTTP POST
> transaction.  Peer certificate cannot be authenticated with known CA
> certificates
> 
> Installation failed. Rolling back changes.
> IPA client is not configured on this system.
> 
> I have attached the log file.
> 
> thank you all once again.
> regards,
> Bhavin
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* Rob Crittenden <rcrit...@redhat.com>
> *Sent:* Monday, October 16, 2017 5:09 AM
> *To:* FreeIPA users list
> *Cc:* John Dennis; Bhavin Vaidya
> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
>  
> Bhavin Vaidya via FreeIPA-users wrote:
>> Thank you. your help is appreciated. We are still out of luck and this
>> is becoming very critical for us.
>>
>>
>> Please help.
>>
>>
>> We did remove all but 1 certificate, restarted master (ds01) but
>> clientinstallation, connection check and replica installation still fails.
>>
>>
>> certutil -D -d /etc/pki/nssdb -n 'ARTERIS.COM IPA CA'
>>
>>
>> the log messages are,
>>
>>
>> /var/log/ipaclient-install.log
>>
>> 2017-10-13T06:25:31Z DEBUG Starting external process
>> 2017-10-13T06:25:31Z DEBUG args=/usr/bin/certutil -d /etc/ipa/nssdb -A
>> -n ARTERIS.COM IPA CA -t CT,C,C -f /etc/ipa/nssdb/pwdfile.txt
>> 2017-10-13T06:25:31Z DEBUG Process finished, return code=255
>> 2017-10-13T06:25:31Z DEBUG stdout=
>> 2017-10-13T06:25:31Z DEBUG stderr=certutil: could not add certificate to
>> token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to
>> database.
>>
>> 2017-10-13T06:25:31Z ERROR Installation failed. Rolling back changes.
>>
>> /var/log/ipareplica-conncheck.log
>>
>> 2017-10-13T01:56:19Z DEBUG Starting external process
>> 2017-10-13T01:56:19Z DEBUG args=/usr/bin/certutil -d /tmp/tmpbrAYYO -A
>> -n CN=Certificate Authority,O=ARTERIS.COM -t C,, -f
>> /tmp/tmpbrAYYO/pwdfile.txt
>> 2017-10-13T01:56:19Z DEBUG Process finished, return code=0
>> 2017-10-13T01:56:19Z DEBUG stdout=
>> 2017-10-13T01:56:19Z DEBUG stderr=
>> 2017-10-13T01:56:19Z DEBUG Starting external process
>> 2017-10-13T01:56:19Z DEBUG args=/usr/bin/certutil -d /tmp/tmpbrAYYO -A
>> -n CN=Certificate Authority,O=ARTERIS.COM -t C,, -f
>> /tmp/tmpbrAYYO/pwdfile.txt
>> 2017-10-13T01:56:19Z DEBUG Process finished, return code=255
>> 2017-10-13T01:56:19Z DEBUG stdout=
>> 2017-10-13T01:56:19Z DEBUG stderr=certutil: could not add certificate to
>> token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to
>> database.
>>
>> Here is the Red Hat thread https://access.redhat.com/solutions/1143193.
> IdM/IPA server install error with external CA, "certutil ...
> <https://access.redhat.com/solutions/1143193>
> access.redhat.com
> Register. If you are a new customer, register now for access to product
> evaluations and purchasing capabilities. Need access to an account? If
> your company has an ...
> 
> 
> 
> 
> This issue is unrelated.
> 
> IPA pulls the list of CA's to add from LDAP so pre-deleting the entries
> locally won't do anything: they will be re-added by ipa-client-install.
> 
> You'll need to look in ARTERIS.COM IPA
> CA,cn=cn=certificates,cn=ipa,cn=etc,dc=ateris,dc=com for
> userCertificate. It is a multi-valued attribute. I'm guessing it occurs
> 5 times. It seems only one of them is problematic, you'll need to figure
> out which one is the "bad" one, or figure out which is the most recent
> and remove the others. I'd be sure to save a copy of whatever is there
> at the moment to be on the safe side.
> 
> rob
> 
>>
>> regards,
>> Bhavin
>>
>> ------------------------------------------------------------------------
>> *From:* Rob Crittenden <rcrit...@redhat.com>
>> *Sent:* Friday, October 13, 2017 5:38 AM
>> *To:* FreeIPA users list; Bhavin Vaidya
>> *Cc:* John Dennis
>> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
>>
>> John Dennis via FreeIPA-users wrote:
>>> On 10/12/2017 05:06 PM, Bhavin Vaidya wrote:
>>>> Hello Jon,
>>>>
>>>>
>>>> thank you for your help. responded to main thread, and just sending
>>>> you the actual output for certutil.
>>>>
>>>>
>>>> [root@ds01 log]#  certutil -d /etc/pki/nssdb -L
>>>>
>>>> Certificate Nickname                                         Trust
>>>> Attributes
>>>>
>>>>   SSL,S/MIME,JAR/XPI
>>>>
>>>> ARTERIS.COM IPA CA                                           CT,C,C
>>>> ARTERIS.COM IPA CA                                           CT,C,C
>>>> ARTERIS.COM IPA CA                                           CT,C,C
>>>> ARTERIS.COM IPA CA                                           CT,C,C
>>>
>>> These nicknames do not look unique to me, I'm assuming you're still
>>> editing them for inclusion in this email.
>>>
>>> But irregardless here is where I'm going with this. Your goal is to
>>> identify the correct cert to use and which to discard. The only way you
>>> can do that is to examine each individual cert. To examine an individual
>>> cert you must have it's *unique* nickname to pass to "certutil -L -a -n
>>> xxx" where xxx is the unique nickname.
>>>
>>> Only you can identify the correct cert once you list them. At the
>>> absolute minimum they should each have a unique (issuer,serial_number)
>>> pair. The one you want to use will probably select based on the issuer
>>> and validity dates.
>>
>> This is how NSS handles multiple copies of the same certificate subject
>> in a given database.
>>
>> My assumption is that the CA was renewed multiple times.
>>
>> This should get you the PEM-encoded copies of the certs:
>>
>> # certutil -D -d /etc/pki/nssdb -n "ARTERIS.COM IPA CA" -a
>>
>> rob
>>
>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* John Dennis <jden...@redhat.com>
>>>> *Sent:* Thursday, October 12, 2017 6:10 AM
>>>> *To:* FreeIPA users list
>>>> *Cc:* Bhavin Vaidya; Rob Crittenden
>>>> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
>>>> On 10/12/2017 03:29 AM, Rob Crittenden via FreeIPA-users wrote:
>>>>> Bhavin Vaidya via FreeIPA-users wrote:
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>> I'm having various problem on our FreeIPA setup, like can not establish
>>>>>> new replica server or add a client anymore. Initially we had
>>>>>> certificate
>>>>>> issue, then we upgraded the Master FreeIPA server (CentOS 7.0.146) to
>>>>>> FreeIPA v4.4.0) few months back.
>>>>>>
>>>>>>
>>>>>> On master server it shows up 4 entries for IPA CA certificate. Is this
>>>>>> normal?
>>>>>>
>>>>>>
>>>>>> [root@ds01 ~]# certutil -d /etc/pki/nssdb -L
>>>>>>
>>>>>> Certificate Nickname                                         Trust
>>>>>> Attributes
>>>>>>
>>>>>>         SSL,S/MIME,JAR/XPI
>>>>>>
>>>>>> EXAMPLE.COM IPA CA                                           CT,C,C
>>>>>> EXAMPLE.COM IPA CA                                           CT,C,C
>>>>>> EXAMPLE.COM IPA CA                                           CT,C,C
>>>>>> EXAMPLE.COM IPA CA                                           CT,C,C
>>>>>
>>>>> The question is: are these all different certificates (and why)? I
>>>>> assume someone ran ipa-cacert-manage renew a bunch of times.
>>>>>
>>>>> Multiple entries in itself shouldn't be a problem.
>>>>>
>>>>> I assume this is related to your client install issues. You may be
>>>>> able to get away with having just the latest CA cert stored in LDAP
>>>>> to avoid this.
>>>>
>>>> I saw this last night and my first thought was this shouldn't happen
>>>> because certutil enforces nickname uniqueness.
>>>>
>>>> We would like to verify what each cert is, specifically it's issuer and
>>>> serial number. But we can't ask certutil to show us the details of a
>>>> cert because you must pass the -n nickname flag to certutil so it can
>>>> find the cert to display. But since the nicknames are not unique you
>>>> can't do that. This is why certutil (and any low level NSS API that adds
>>>> a cert to the db) demands name uniqueness.
>>>>
>>>> Are the names listed with -L truly unique? It looks like you edited them.
>>>>
>>>>
>>>> --
>>>> John
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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

Reply via email to