[Freeipa-users] Replica issue / Certificate Authority

Florence Blanc-Renaud flo at redhat.com
Wed Jan 4 12:49:08 UTC 2017


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-bounces at redhat.com [mailto:freeipa-users-
>> bounces at redhat.com] On Behalf Of Fraser Tweedale
>> Sent: lundi 19 décembre 2016 00:11
>> To: Christopher Young <mexigabacho at gmail.com>
>> Cc: freeipa-users at 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 at 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 at 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
>>>> <mexigabacho at 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 at ipa01 ~]# ipa-replica-manage list
>>>>> ipa01.passur.local: master
>>>>> ipa02.passur.local: master
>>>>> -----
>>>>> [root at 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 at 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 at 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
>>
>>




More information about the Freeipa-users mailing list