On 10/23/2017 08:59 PM, Bhavin Vaidya via FreeIPA-users wrote:
> Hello Rob,
>
>
> here what we have. Looks like /etc/http/alias certificate is different,
> as it is from Sug 03 2014 through Aug 03 2034, which is original date.
>
If /etc/httpd/alias does not contain the latest IPA CA certificate,
running ipa-certupdate should fix this. The tool gets certificates from
cn=certificates,cn=ipa,cn=etc,$BASEDN so you need to make sure that the
latest one is present in this tree.
It will also update /etc/dirsrv/slapd-DOMxx, /etc/ipa/ca.crt and
/etc/ipa/nssdb. It can be run on all IPA hosts (masters or clients).
Flo.
>
> [root@ds01 alias]# certutil -L -d /etc/httpd/alias/
>
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
>
> ipaCert u,u,u
> Server-Cert u,u,u
> EXAMPLE.COM IPA CA CT,C,C
>
> [root@ds01 alias]# certutil -d /etc/httpd/alias/ -L -n "EXAMPLE.COM IPA CA"
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 1 (0x1)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
> Validity:
> Not Before: Sun Aug 03 19:28:18 2014
> Not After : Thu Aug 03 19:28:18 2034
> Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
> Subject Public Key Info:
> Public Key Algorithm: PKCS #1 RSA Encryption
> RSA Public Key:
> Modulus:
> c3:9d:33:68:81:3a:7e:83:15:ba:bd:54:1c:a3:28:6a:
> <SNIP>
>
> Exponent: 65537 (0x10001)
> Signed Extensions:
> Name: Certificate Authority Key Identifier
> Key ID:
> 48:da:13:cd<SNIP>:37:06:74:ac:
> da:f7:6d:c6
>
> Name: Certificate Basic Constraints
> Critical: True
> Data: Is a CA with no maximum path length.
>
> Name: Certificate Key Usage
> Critical: True
> Usages: Digital Signature
> Non-Repudiation
> Certificate Signing
> CRL Signing
>
> Name: Certificate Subject Key ID
> Data:
> 48:da:13:cd<SNIP>:37:06:74:ac:
> da:f7:6d:c6
>
> Name: Authority Information Access
> Method: PKIX Online Certificate Status Protocol
> Location:
> URI: "
http://ipa01.example.com:80/ca/ocsp"
>
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Signature:
> 7e:bb:1e:d8:f7:2c:57:45:57:2a:cb:a9:43:a9:1e:88:
> <SNIP>
> Fingerprint (SHA-256):
> 64:<SNIP>:1C
> Fingerprint (SHA1):
> 28:<SNIP:85
>
> Certificate Trust Flags:
> SSL Flags:
> Valid CA
> Trusted CA
> Trusted Client CA
> Email Flags:
> Valid CA
> Trusted CA
> Object Signing Flags:
> Valid CA
> Trusted CA
>
>
>
>
>
> How can we promote or update all the certificates on first master, then
> replica and client? Will we have to reboot or re-install client?
>
> thank you and with regards,
> Bhavin
>
> ------------------------------------------------------------------------
> *From:* Rob Crittenden <rcritten@redhat.com>
> *Sent:* Monday, October 23, 2017 11:14 AM
> *To:* Anvar Kuchkartaev; Bhavin Vaidya via FreeIPA-users
> *Cc:* John Dennis; Bhavin Vaidya
> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
> Anvar Kuchkartaev wrote:
>> Have you tried to add CA to systemwide database?
>
> It gets added as part of ipa-client-install, after the point where it is
> failing.
>
> This leads me to believe you don't have the "right" CA certificate after
> all.
>
> Is your Apache web cert signed by the IPA CA or a 3rd party? If by IPA
> then I'd compare the CA cert in the NSS db in /etc/httpd/alias with the
> one you have in LDAP.
>
> mod_nss won't let Apache start with a bad cert chain.
>
> rob
>
>>
>> Anvar Kuchkartaev
>> anvar@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 <rcritten@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.
|
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 ...
|
> 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 ...
|
> 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 ...
>
>
>
>> 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 ...
|
> 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 ...
|
> 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 ...
>
>
>
>> 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 <rcritten@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 <jdennis@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-leave@lists.fedorahosted.org
>>>
>>
>>
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
>