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
