Hi Flo,

The id needed to execute that command would come from where exactly? Is it the 
one from getcert list -n ipaCert?

Thanks
Christophe 

Sent from my iPhone

> On 4 Jan 2017, at 13:49, Florence Blanc-Renaud <f...@redhat.com> wrote:
> 
>> On 01/04/2017 12:41 PM, Christophe TREFOIS wrote:
>> Hi Fraser,
>> 
>> We encountered the same issue. We exported the certificate from a "good"
>> replica, using certutil.
>> We then used certutil -A -n ipaCert -d /etc/httpd/alias/ -i
>> /opt/sysadmin/cacert.crt -a -t CT,C on the bad server and then restarted
>> ipa, and certmonger.
>> 
>> Now, the certificate is correct both using the certutil command and the
>> getcert list -n ipaCert command.
>> 
>> However, we see an "ca-error: Invalid cookie: ''  "  in the output of
>> getcert list -n ipaCert.
>> 
> Hi Christophe,
> 
> is this error displayed on the renewal master? If not, you can run
> $ getcert resubmit -i <id for ipaCert>
> and the error should go away. On non-renewal master, resubmit downloads the 
> certificate from LDAP (it does not ask for renewal), meaning that this 
> operation cannot be harmful.
> 
> To know which server is the renewal master:
> $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password -b 
> "cn=masters,cn=ipa,cn=etc,$BASEDN" 
> '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
> dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,$BASEDN
> 
> => the renewal master is server.example.com
> 
> HTH,
> Flo
> 
>> Did we import the certificate correctly and should we worry about this
>> ca-error?
>> It seems replication is going fine, and also ipa-server-upgrade completes
>> successfully when run manually (whereas it failed previously from the same
>> error as in this thread)
>> 
>> Thanks for any pointers on how to clean the issue up properly,
>> Kind regards,
>> 
>> Christophe
>> 
>>> -----Original Message-----
>>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>>> boun...@redhat.com] On Behalf Of Fraser Tweedale
>>> Sent: lundi 19 d├ęcembre 2016 00:11
>>> To: Christopher Young <mexigaba...@gmail.com>
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Replica issue / Certificate Authority
>>> 
>>>> On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:
>>>> Christopher Young wrote:
>>>>> Ok.  I think I have a 'hint' here, but I could use some help getting
>> this fixed.
>>>>> 
>>>>> Comparing the two IPA servers, I found the following (modified SOME
>>>>> of the output myself):
>>>> 
>>>> You're right about the ipaCert. I'd export the renewed cert from your
>>>> working server using the same certutil command, just direct it to a
>>>> file instead. Then import it into the non-working server and restart
>>>> the httpd service. That should do it.
>>>> 
>>> I agree that this should fix it.
>>> 
>>> You could also try running `ipa-certupdate' as root, if the correct
>> certificate is
>>> to be found in cn=certificates,cn=ipa,cn=etc,{basedn}
>>> 
>>> Once everything is working again, you should check:
>>> 
>>> 1. renewal master configuration is correct
>>> 
>>> 2. certmonger tracking requests for the IPA RA cert are correct on
>>>   both servers
>>> 
>>> 3. the correct certificate is in
>>>   cn=certificates,cn=ipa,cn=etc,{basedn}
>>> 
>>> Thanks,
>>> Fraser
>>> 
>>>> Or you can try restarting certmonger on the non-working server to see
>>>> if
>>>> 
>>>> that triggers it to pull in the updated cert. Theoretically this
>>>> should do it as well but given potential past replication problems it
>>>> is possible the entry doesn't exist.
>>>> 
>>>> getcert list -n ipaCert on each will show some basic information. The
>>>> important thing is to see if there is some root cause that will make
>>>> this blow up again at renewal time.
>>>> 
>>>> rob
>>>> 
>>>>> 
>>>>> on 'ipa02' (the 'good' one):
>>>>> -----
>>>>> ipa cert-show 1
>>>>>  Issuing CA: ipa
>>>>>  Certificate: <<<proper cert data here>>>
>>>>>  Subject: CN=Certificate Authority,O=xxxx.LOCAL
>>>>>  Issuer: CN=Certificate Authority,O=xxxx.LOCAL
>>>>>  Not Before: Thu Jan 01 06:23:38 2015 UTC
>>>>>  Not After: Mon Jan 01 06:23:38 2035 UTC
>>>>>  Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
>>>>>  Fingerprint (SHA1):
>>>>> 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
>>>>>  Serial number: 1
>>>>>  Serial number (hex): 0x1
>>>>>  Revoked: False
>>>>> ------
>>>>> 
>>>>> 
>>>>> on 'ipa01'
>>>>> -----
>>>>> ipa cert-show 1
>>>>> ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
>>>>> (Invalid Credential.)
>>>>> -----
>>>>> 
>>>>> Thinking about this, I decided to just start checking for
>>>>> inconsistencies and I noticed the following:
>>>>> 
>>>>> ipa02:
>>>>> -----------
>>>>> [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
>>>>> openssl x509 -text  | head
>>>>> Certificate:
>>>>>    Data:
>>>>>        Version: 3 (0x2)
>>>>>        Serial Number: 268304413 (0xffe001d)
>>>>>    Signature Algorithm: sha256WithRSAEncryption
>>>>>        Issuer: O=xxxxx.LOCAL, CN=Certificate Authority
>>>>>        Validity
>>>>>            Not Before: Nov 23 18:19:31 2016 GMT
>>>>>            Not After : Nov 13 18:19:31 2018 GMT
>>>>>        Subject: O=xxxxx.LOCAL, CN=IPA RA
>>>>> 
>>>>> ----------
>>>>> ipa01:
>>>>> ----------
>>>>> [root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
>>>>> openssl x509 -text  | head
>>>>> Certificate:
>>>>>    Data:
>>>>>        Version: 3 (0x2)
>>>>>        Serial Number: 7 (0x7)
>>>>>    Signature Algorithm: sha256WithRSAEncryption
>>>>>        Issuer: O=xxxx.LOCAL, CN=Certificate Authority
>>>>>        Validity
>>>>>            Not Before: Jan  1 06:24:23 2015 GMT
>>>>>            Not After : Dec 21 06:24:23 2016 GMT
>>>>>        Subject: O=xxxx.LOCAL, CN=IPA RA
>>>>> 
>>>>> ----------
>>>>> 
>>>>> So, it looks like somewhere in the process, the certificate got
>>>>> renewed but not updated on 'ipa01'?  I apologize as I'm trying to
>>>>> understand this.  I believe that my end goal is probably still the
>>>>> same (verify replication and get things working properly on the
>>>>> 'ipa01' system.
>>>>> 
>>>>> Any help is very much appreciated!
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>> 
>>>>> On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young
>>>>> <mexigaba...@gmail.com> wrote:
>>>>>> I'm hoping to provide enough information to get some help to a very
>>>>>> important issue that I'm currently having.
>>>>>> 
>>>>>> I have two IPA servers at a single location that recently had a
>>>>>> replication issue that I eventually resolved by reinitializing one
>>>>>> of the masters/replicas with one that seemed to be the most 'good'.
>>>>>> 
>>>>>> In any case, somewhere in this process, the new IPA 4.4 was release
>>>>>> with/for CentOS 7.3.
>>>>>> 
>>>>>> At this moment, regular replication seems to be working properly
>>>>>> (in that I don't have any obvious issues and web interfaces on both
>>>>>> systems seem to be consistent for updates EXCEPT when it comes to
>>>>>> the certificates).
>>>>>> 
>>>>>> Before I get to the errors, here is the output of some of the
>>>>>> commands that I would expect anyone would need:
>>>>>> 
>>>>>> ----------
>>>>>> [root@ipa01 ~]# ipa-replica-manage list
>>>>>> ipa01.passur.local: master
>>>>>> ipa02.passur.local: master
>>>>>> -----
>>>>>> [root@ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local
>>>>>> ipa02.passur.local: replica
>>>>>>  last init status: None
>>>>>>  last init ended: 1970-01-01 00:00:00+00:00
>>>>>>  last update status: Error (0) Replica acquired successfully:
>>>>>> Incremental update succeeded
>>>>>>  last update ended: 2016-12-16 20:25:40+00:00
>>>>>> -----
>>>>>> [root@ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local
>>>>>> ipa01.passur.local: replica
>>>>>>  last init status: None
>>>>>>  last init ended: 1970-01-01 00:00:00+00:00
>>>>>>  last update status: Error (0) Replica acquired successfully:
>>>>>> Incremental update succeeded
>>>>>>  last update ended: 2016-12-16 20:25:40+00:00
>>>>>> -----
>>>>>> [root@ipa01 ~]# ipa-replica-manage list-ruv Replica Update Vectors:
>>>>>>        ipa01.passur.local:389: 4
>>>>>>        ipa02.passur.local:389: 6
>>>>>> Certificate Server Replica Update Vectors:
>>>>>>        ipa02.passur.local:389: 97
>>>>>>        ipa01.passur.local:389: 96
>>>>>> ----------
>>>>>> 
>>>>>> 
>>>>>> After the yum updates were applied to each system, I noticed that the
>>>>>> results of 'ipa-server-upgrade' were quite different.  The 'ipa02'
>>>>>> system went through without errors (this was also the system I used
>> to
>>>>>> reinitialize the other when I had a replication issue recently).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 'ipa01', I have following at the end of the 'ipaupgrade.log' file:
>>>>>> ----------
>>>>>> 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect
>>>>>> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
>>>>>> 2016-12-14T18:09:26Z DEBUG   File
>>>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171,
>>>>>> in execute
>>>>>>    return_value = self.run()
>>>>>>  File "/usr/lib/python2.7/site-
>>> packages/ipaserver/install/ipa_server_upgrade.py",
>>>>>> line 46, in run
>>>>>>    server.upgrade()
>>>>>>  File "/usr/lib/python2.7/site-
>>> packages/ipaserver/install/server/upgrade.py",
>>>>>> line 1863, in upgrade
>>>>>>    upgrade_configuration()
>>>>>>  File "/usr/lib/python2.7/site-
>>> packages/ipaserver/install/server/upgrade.py",
>>>>>> line 1785, in upgrade_configuration
>>>>>>    ca_enable_ldap_profile_subsystem(ca)
>>>>>>  File "/usr/lib/python2.7/site-
>>> packages/ipaserver/install/server/upgrade.py",
>>>>>> line 336, in ca_enable_ldap_profile_subsystem
>>>>>>    cainstance.migrate_profiles_to_ldap()
>>>>>>  File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>>>> line 1984, in migrate_profiles_to_ldap
>>>>>>    _create_dogtag_profile(profile_id, profile_data, overwrite=False)
>>>>>>  File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>>>> line 1990, in _create_dogtag_profile
>>>>>>    with api.Backend.ra_certprofile as profile_api:
>>>>>>  File
>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py",
>>>>>> line 2060, in __enter__
>>>>>>    raise errors.RemoteRetrieveError(reason=_('Failed to authenticate
>>>>>> to CA REST API'))
>>>>>> 
>>>>>> 2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed,
>>>>>> exception: RemoteRetrieveError: Failed to authenticate to CA REST API
>>>>>> 2016-12-14T18:09:26Z ERROR Unexpected error - see
>>>>>> /var/log/ipaupgrade.log for details:
>>>>>> RemoteRetrieveError: Failed to authenticate to CA REST API
>>>>>> 2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed.
>>> See
>>>>>> /var/log/ipaupgrade.log for more information
>>>>>> ----------
>>>>>> 
>>>>>> 
>>>>>> In addition, when I go to the IPA web interface on the 'ipa01'
>> system,
>>>>>> I get the following when I try to view any of the certificates:
>>>>>> ----------
>>>>>> IPA Error 4301: CertificateOperationError
>>>>>> 
>>>>>> Certificate operation cannot be completed: EXCEPTION (Invalid
>>> Credential.)
>>>>>> ----------
>>>>>> 
>>>>>> 
>>>>>> I was wondering if there was a method for taking all the CA
>>>>>> details/tree/what have you from my 'ipa02' system and using it to
>>>>>> repopulate the 'ipa01'.   Since everything else seems to be working
>>>>>> correctly after a reinitialize on 'ipa01', I thought this would be
>> the
>>>>>> safest way, but I'm opening any solutions as I need to get this fixed
>>>>>> ASAP.
>>>>>> 
>>>>>> Please let me know any additional details that may help OR if there
>> is
>>>>>> a procedure that I could use to quickly and easily recreate 'ipa01'
>>>>>> WITH the certificate authority properly working on both.  I may need
>>>>>> some educate there.
>>>>>> 
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> -- Chris
>>>>> 
>>>> 
>>>> --
>>>> Manage your subscription for the Freeipa-users mailing list:
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> Go to http://freeipa.org for more info on the project
>>> 
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
>>> 
>>> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to