I think this has resolved itself on its own after the update to RHEL 7.4.
So that was a pleasant surprise.
On Wed, Aug 2, 2017 at 8:53 AM, Prasun Gera <prasun.gera(a)gmail.com> wrote:
I think the path that is triggered first is from the following code:
if new_cert == old_cert:
syslog.syslog(syslog.LOG_INFO, "Updated certificate not
available")
# No cert available yet, tell certmonger to wait another 8 hours
return (WAIT_WITH_DELAY, 8 * 60 * 60, '')
This causes the status to change to CA_WORKING for a while. Later, the
status changes to the cookie error. The old cert is still valid. So is it
supposed to get a new cert ?
On Mon, Jul 31, 2017 at 2:51 PM, Prasun Gera <prasun.gera(a)gmail.com>
wrote:
> They are published, or at least it would seem that way. These were my
> queries:
> ldapsearch -h ipa_master -x -D 'cn=directory manager' -b
> cn="subsystemCert
cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc=<basedn> -W
> ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b
> cn="subsystemCert
cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc=<basedn> -W
> On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
> "subsystemCert cert-pki-ca" -a
> On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
> "subsystemCert cert-pki-ca" -a
>
> They all return the same cert.
>
> Also, there was another thread on the mailing list with similar symptoms.
> I'm not sure if there was a resolution.
>
https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html
>
>
>
> On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden <rcritten(a)redhat.com>
> wrote:
>
>> Prasun Gera via FreeIPA-users wrote:
>> > The entry is present on both master, and replica. Also, the status on
>> > replica for those two has changed to *'ca-error: Invalid cookie:
'''*.
>> > The certs listed by certutil on both systems, as well as the ones
>> listed
>> > by the ldap query seem to match. When I try to resubmit, there is also
>> > this message in the system log "dogtag-ipa-ca-renew-agent-submit:
>> > Updated certificate not available". Any way to run some diagnostics on
>> > the newly added dogtag-ipa-ca-renew-agent on the replica ?
>>
>> Did you follow Flo's previous advice and look in LDAP to see if the
>> updated certificates were published? It would seem that they were not.
>>
>> rob
>>
>> >
>> > On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud <flo(a)redhat.com
>> > <mailto:flo@redhat.com>> wrote:
>> >
>> > On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
>> >
>> > Sorry about this rather long thread, and I appreciate all the
>> > help. After adding the new ca, the new tracking requests show
>> > the status as "CA_WORKING" instead of
"MONITORING".
>> >
>> > For example, the replica shows this for one of the requests:
>> > Request ID '20170727122353':
>> > status: CA_WORKING
>> > stuck: no
>> > key pair storage:
>> >
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>> caSigningCert
>> > cert-pki-ca',token='NSS Certificate DB',pin set
>> > certificate:
>> >
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>> caSigningCert
>> > cert-pki-ca',token='NSS Certificate DB'
>> > CA: dogtag-ipa-ca-renew-agent
>> > issuer: CN=Certificate
Authority,O=ORG.EDU <
http://ORG.EDU>
>> > <
http://ORG.EDU>
>> > subject: CN=Certificate
Authority,O=ORG.EDU <
http://ORG.EDU>
>> > <
http://ORG.EDU>
>> > expires: 2035-04-08 17:34:47 UTC
>> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> > "caSigningCert cert-pki-ca"
>> > track: yes
>> > auto-renew: yes
>> >
>> > Same status for subsystemCert cert-pki-ca. However, ipaCert
>> > shows monitoring, which is also tracked by
>> > dogtag-ipa-ca-renew-agent. There are still a few more left that
>> > I need to add. Is this status normal ?
>> >
>> >
>> > On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud
>> > <flo(a)redhat.com <mailto:flo@redhat.com>
<mailto:flo@redhat.com
>> > <mailto:flo@redhat.com>>> wrote:
>> >
>> > On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users
>> wrote:
>> >
>> > I tried to replicate every one of those on the replica,
>> > but I've
>> > hit a
>> > snag. The following CA only exists on the master, but
>> > not on the
>> > replica:
>> >
>> > CA 'dogtag-ipa-ca-renew-agent':
>> > is-default: no
>> > ca-type: EXTERNAL
>> > helper-location:
>> > /usr/libexec/certmonger/dogta
>> g-ipa-ca-renew-agent-submit
>> >
>> > I didn't notice that there were two different
>> > CAs, dogtag-ipa-renew-agent and
>> > dogtag-ipa-ca-renew-agent; the
>> > former is
>> > there on the replica. I seem to have accidentally
>> assigned
>> > dogtag-ipa-renew-agent to ipaCert on the replica. It
>> > didn't show any
>> > errors, and seems to be monitoring. I stopped creating
>> the
>> > monitoring
>> > requests once I realized this. How do I fix this ?
>> >
>> > Hi,
>> >
>> > you need first to add the CA on the replica with getcert
>> add-ca:
>> > $ sudo getcert add-ca -c dogtag-ipa-ca-renew-agent -e
>> > /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>> >
>> > Then fix the CA used to renew ipaCert:
>> > - stop tracking with dogtag-ipa-renew-agent
>> > $ sudo getcert stop-tracking -i <id>
>> >
>> > - start tracking with dogtag-ipa-ca-renew-agent using
>> getcert
>> > start-tracking + the same options as you did except for
>> the -c
>> > dogtag-ipa-ca-renew-agent
>> >
>> > HTH,
>> > Flo
>> >
>> >
>> >
>> > On Wed, Jul 19, 2017 at 6:23 AM, Fraser Tweedale
>> > <ftweedal(a)redhat.com <mailto:ftweedal@redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>
>> > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>>>
>> wrote:
>> >
>> > On Wed, Jul 19, 2017 at 05:31:20AM -0400, Prasun
>> > Gera wrote:
>> > > Thank you, Fraser. That works. I also added the
>> > post-script command
>> > >
"/usr/libexec/ipa/certmonger/restart_httpd".
>> Upon
>> > comparing with the
>> > > master, there are quite a few certs that are
>> > tracked on
>> > the master, and
>> > > none on the replica. Do I need to do this same
>> > exercise
>> > for every cert on
>> > > the replica ? These are the nicknames of the
>> > certs that
>> > are tracked on the
>> > > master:
>> > >
>> > > -
>> > location='/etc/httpd/alias',nickname='Signing-Cert'
>> > > -
>> >
>> >
location='/etc/pki/pki-tomcat/alias',nickname='auditSigning
>> Cert
>> > > cert-pki-ca'
>> > > -
>> >
>> >
location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> > > cert-pki-ca'
>> > > -
>> > location='/etc/pki/pki-tomcat
>> /alias',nickname='subsystemCert
>> > > cert-pki-ca'
>> > > -
>> > location='/etc/pki/pki-tomcat
>> /alias',nickname='caSigningCert
>> > > cert-pki-ca'
>> > > - location='/etc/httpd/alias',ni
>> ckname='ipaCert'
>> > > -
>> > location='/etc/pki/pki-tomcat
>> /alias',nickname='Server-Cert
>> > cert-pki-ca'
>> > > -
>> >
location='/etc/dirsrv/slapd-ORG',nickname='Server-Cert'
>> > > -
>> > location='/etc/httpd/alias',nickname='Server-Cert'
>> > >
>> > Strongly advised to track these with equivalent
>> > parameters
>> > to what
>> > you find on the master.
>> >
>> > Cheers,
>> > Fraser
>> >
>> > >
>> > > On Mon, Jul 17, 2017 at 8:58 PM, Fraser Tweedale
>> > <ftweedal(a)redhat.com <mailto:ftweedal@redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>
>> > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>>>
>> >
>> > > wrote:
>> > >
>> > > > On Mon, Jul 17, 2017 at 02:06:36PM -0400,
>> > Prasun Gera
>> > wrote:
>> > > > > Hi Fraser,
>> > > > > I ran that command on the replica (which
is
>> > where it
>> > needs to be run,
>> > > > right
>> > > > > ? ), and it finished without any error.
>> > However, when
>> > I called
>> > > > ipa-getcert
>> > > > > list, it shows an error:
>> > > > >
>> > > > > Request ID '20170717180008':
>> > > > > status: MONITORING
>> > > > > * ca-error: Unable to determine
principal
>> > name for
>> > signing request.*
>> > > > > stuck: no
>> > > > > key pair storage:
>> > > > >
>> >
>> >
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cer
>> t',token='NSS
>> > > > > Certificate
>> > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> > > > > certificate:
>> > > > >
>> >
>> >
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cer
>> t',token='NSS
>> > > > > Certificate DB'
>> > > > > CA: IPA
>> > > > > issuer: CN=Certificate Authority,O=ORG
>> > > > > subject:
CN=replica.com
<
http://replica.com
>> >
>> > <
http://replica.com>
>> > <
http://replica.com>,O=ORG
>> > > > > expires: 2017-08-27 22:55:11 UTC
>> > > > > key usage:
>> > digitalSignature,nonRepudiation,keyEncipherment,
>> > > > dataEncipherment
>> > > > > eku: id-kp-serverAuth,id-kp-clientAuth
>> > > > > pre-save command:
>> > > > > post-save command:
>> > > > > track: yes
>> > > > > auto-renew: yes
>> > > > >
>> > > > Hi Prasun,
>> > > >
>> > > > I looks like, for some reason the princpial
>> > name (-K)
>> > and dns name
>> > > > (-D) did not make it into the tracking
>> > request. Perhaps I gave you
>> > > > an incorrect usage of `getcert
>> start-tracking' (or
>> > possibly a bug).
>> > > > Anyhow, try:
>> > > >
>> > > > getcert resubmit -i <request-id> -K
>> > <principal-name>
>> > -D <dns-name>
>> > > >
>> > > > Hopefully that will cause the principal name
>> to
>> > get set
>> > properly.
>> > > >
>> > > > Cheers,
>> > > > Fraser
>> > > >
>> > > > > On Mon, Jul 17, 2017 at 9:36 AM, Fraser
>> Tweedale
>> > <ftweedal(a)redhat.com
<mailto:ftweedal@redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>
>> > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>>>
>> >
>> >
>> > > > > wrote:
>> > > > >
>> > > > > > On Mon, Jul 17, 2017 at 08:41:26AM
-0400,
>> > Prasun
>> > Gera wrote:
>> > > > > > > Bumping this for help. I need
to renew
>> my
>> > replica's SSL
>> > certificate
>> > > > which
>> > > > > > > will expire in a month, but I
can't
>> find any
>> > instructions.
>> > It looks
>> > > > like
>> > > > > > > the replica's web-ui cert
isn't tracked
>> > by the
>> > master or the
>> > > > replica. I'm
>> > > > > > > using a pretty stock
installation with
>> no
>> > external CAs or
>> > certs. So
>> > > > > > > ideally, all of this should
have been
>> handled
>> > automatically by ipa,
>> > > > but
>> > > > > > it
>> > > > > > > isn't. There have also
been quite a few
>> cert
>> > related posts
>> > of late
>> > > > which
>> > > > > > > makes me think if there are
(were) some
>> other
>> > issues with
>> > replica
>> > > > setup a
>> > > > > > > couple of years ago, which is
when the
>> > certs were
>> > originally
>> > > > generated.
>> > > > > > >
>> > > > > > Hi Prasun,
>> > > > > >
>> > > > > > You can add a tracking request to
>> > Certmonger for
>> > the cert:
>> > > > > >
>> > > > > > % ipa-getcert start-tracking
-d
>> > /etc/httpd/alias -n
>> > Server-Cert \
>> > > > > > -p
/etc/httpd/alias/pwdfile.txt \
>> > > > > > -K
ldap/<hostname>@<realm> -D
>> <hostname>
>> > > > > >
>> > > > > > The `-D <hostname>` option
will ensure
>> that
>> > the CSR
>> > contains the
>> > > > > > subject alt name for
<hostname>, which
>> will
>> > in turn be
>> > propagated to
>> > > > > > the issued certificiate.
>> > > > > >
>> > > > > > Once the tracking request is set up
you
>> can
>> > renew
>> > the cert via
>> > > > > > `ipa-getcert resubmit -i
<request-id>`.
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Fraser
>> > > > > >
>> > > > > > > On Sun, Apr 23, 2017 at 10:08
PM,
>> Prasun Gera
>> > <prasun.gera(a)gmail.com
>> > <mailto:prasun.gera@gmail.com>
<mailto:prasun.gera@gmail.com
>> > <mailto:prasun.gera@gmail.com>>
>> > <mailto:prasun.gera@gmail.com
>> > <mailto:prasun.gera@gmail.com>
<mailto:prasun.gera@gmail.com
>> > <mailto:prasun.gera@gmail.com>>>
>> > > > >
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > I tried that, but the
replica's
>> > "getcert list"
>> > doesn't
>> > seem to
>> > > > show any
>> > > > > > > > results. "Number of
certificates and
>> > requests being
>> > tracked: 0." Is
>> > > > > > that
>> > > > > > > > expected ?
>> > > > > > > >
>> > > > > > > > On Sun, Apr 23, 2017 at
8:50 PM,
>> Fraser
>> > Tweedale <
>> > > > ftweedal(a)redhat.com
>> > <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>> > <mailto:ftweedal@redhat.com>>
>> > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>>>
>> >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > >> On Sun, Apr 23, 2017
at 03:32:19AM
>> -0400,
>> > Prasun Gera
>> > wrote:
>> > > > > > > >> > Thank you. That
worked for the
>> > master. How
>> > do I fix the
>> > > > replica's
>> > > > > > cert ?
>> > > > > > > >> > This is on
>> > ipa-server-4.4.0-14.el7_3.7.x86_64 on
>> > RHEL7. I am
>> > > > not
>> > > > > > using
>> > > > > > > >> > ipa's DNS at
all. Did this happen
>> > because of
>> > that ?
>> > > > > > > >> >
>> > > > > > > >> This is not related
to DNS.
>> > > > > > > >>
>> > > > > > > >> To fix the replica,
log onto the
>> host and
>> > perform the
>> > same steps
>> > > > > > > >> with Certmonger
there. The tracking
>> > Request
>> > ID will be
>> > different
>> > > > > > > >> but otherwise the
process is the
>> same.
>> > > > > > > >>
>> > > > > > > >> Cheers,
>> > > > > > > >> Fraser
>> > > > > > > >>
>> > > > > > > >> > On Thu, Apr 20,
2017 at 9:06 PM,
>> Fraser
>> > Tweedale <
>> > > > > > ftweedal(a)redhat.com
>> > <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>> > <mailto:ftweedal@redhat.com>>
>> > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)redhat.com>
>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@redhat.com>>>>
>> > > > > > > >> > wrote:
>> > > > > > > >> >
>> > > > > > > >> > > On Thu, Apr
20, 2017 at
>> 07:31:16PM
>> > -0400,
>> > Prasun
>> > Gera wrote:
>> > > > > > > >> > > > I can
confirm that I see this
>> > behaviour
>> > too. My
>> > ipa server
>> > > > > > install
>> > > > > > > >> is a
>> > > > > > > >> > > > pretty
stock install with no
>> 3rd
>> > party
>> > certificates.
>> > > > > > > >> > > >
>> > > > > > > >> > > > On
Thu, Apr 20, 2017 at 5:46
>> PM,
>> > Simon
>> > Williams <
>> > > > > > > >> > > >
simon.williams(a)thehelpfulcat.c
>> om
>> > <mailto:simon.williams@thehelpfulcat.com>
>> > <mailto:simon.williams@thehelpfulcat.com
>> > <mailto:simon.williams@thehelpfulcat.com>>
>> > <mailto:simon.williams@thehelpfulcat.com
>> > <mailto:simon.williams@thehelpfulcat.com>
>> >
>> > <mailto:simon.williams@thehelpfulcat.com
>> > <mailto:simon.williams@thehelpfulcat.com>>>> wrote:
>> > > > > > > >> > > >
>> > > > > > > >> > > > >
Yesterday, Chrome on both my
>> > Ubuntu
>> > and Windows
>> > machines
>> > > > > > updated
>> > > > > > > >> to
>> > > > > > > >> > > > >
version 58.0.3029.81. It
>> > appears that
>> > this
>> > version of
>> > > > Chrome
>> > > > > > > >> will not
>> > > > > > > >> > > > >
trust certificates based on
>> > Common Name.
>> > Looking at the
>> > > > > > Chrome
>> > > > > > > >> > > > >
documentation and borne out
>> by
>> > one of the
>> > messages, from
>> > > > > > Chrome
>> > > > > > > >> 58,
>> > > > > > > >> > > > >
the subjectAltName is
>> required to
>> > identify the
>> > DNS name
>> > > > of the
>> > > > > > > >> host
>> > > > > > > >> > > that
>> > > > > > > >> > > > >
the certificate is issued
>> > for. I would be
>> > grateful if
>> > > > someone
>> > > > > > > >> could
>> > > > > > > >> > > point
>> > > > > > > >> > > > >
me in the direction of how to
>> > recreate
>> > my SSL
>> > > > certificates so
>> > > > > > that
>> > > > > > > >> > > > >
the subjectAltName is
>> populated.
>> > > > > > > >> > > > >
>> > > > > > > >> > > > >
Thanks in advance
>> > > > > > > >> > > > >
>> > > > > > > >> > > > >
--
>> > > > > > > >> > > > >
Manage your subscription for
>> the
>> > Freeipa-users
>> > mailing
>> > > > list:
>> > > > > > > >> > > > >
>> >
https://www.redhat.com/mailman/listinfo/freeipa-users
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users>
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users>>
>> >
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users>
>> > <
https://www.redhat.com/mailman/listinfo/freeipa-users
>> >
<
https://www.redhat.com/mailman/listinfo/freeipa-users>>>
>> > > > > > > >> > > > >
Go to
http://freeipa.org for
>> > more info
>> > on the
>> > project
>> > > > > > > >> > > > >
>> > > > > > > >> > > Which
version of IPA are you
>> using?
>> > > > > > > >> > >
>> > > > > > > >> > > The first
thing you should do,
>> which I
>> > think should be
>> > > > sufficient
>> > > > > > in
>> > > > > > > >> > > most cases,
is to tell
>> certmonger to
>> > submit a new cert
>> > > > request for
>> > > > > > > >> > > each
affected certificate,
>> > instructing to
>> > include
>> > the relevant
>> > > > > > > >> > > DNSName in
the subjectAltName
>> > extension in
>> > the CSR.
>> > > > > > > >> > >
>> > > > > > > >> > > To list
certmonger tracking
>> > requests and
>> > look for
>> > the HTTPS
>> > > > > > > >> > >
certificate. For example:
>> > > > > > > >> > >
>> > > > > > > >> > > $
getcert list
>> > > > > > > >> > > Number
of certificate and
>> > requests being
>> > tracked: 11
>> > > > > > > >> > > ...
>> > > > > > > >> > > Request
ID '20170418012901':
>> > > > > > > >> > >
status: MONITORING
>> > > > > > > >> > >
stuck: no
>> > > > > > > >> > >
key pair storage:
>> > type=NSSDB,location='/etc/
>> > > > > > > >> > >
>> > httpd/alias',nickname='Server-Cert',token='NSS
>> > Certificate
>> > > > > > > >> > >
>> > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> > > > > > > >> > >
certificate:
>> > type=NSSDB,location='/etc/
>> > > > > > > >> > >
>> > httpd/alias',nickname='Server-Cert',token='NSS
>> > Certificate
>> > > > DB'
>> > > > > > > >> > >
CA: IPA
>> > > > > > > >> > >
issuer:
>> CN=Certificate
>> > Authority,O=IPA.LOCAL
>> > > > > > 201703211317
>> > > > > > > >> > >
subject:
>> > CN=f25-2.ipa.local,O=IPA.LOCAL
>> > > > 201703211317
>> > > > > > > >> > >
expires: 2019-03-22
>> > 03:20:19 UTC
>> > > > > > > >> > >
dns: f25-2.ipa.local
>> > > > > > > >> > >
key usage:
>> > digitalSignature,nonRepudiatio
>> > > > > > > >> n,keyEncipherment,
>> > > > > > > >> > >
dataEncipherment
>> > > > > > > >> > >
eku:
>> > id-kp-serverAuth,id-kp-clientAuth
>> > > > > > > >> > >
pre-save command:
>> > > > > > > >> > >
post-save command:
>> > /usr/libexec/ipa/certmonger/re
>> > > > > > > >> start_httpd
>> > > > > > > >> > >
track: yes
>> > > > > > > >> > >
auto-renew: yes
>> > > > > > > >> > > ...
>> > > > > > > >> > >
>> > > > > > > >> > > Using the
Request ID of the HTTPS
>> > certificate,
>> > resubmit the
>> > > > > > request
>> > > > > > > >> > > but use the
``-D <hostname>``
>> > option to
>> > specify a
>> > DNSName to
>> > > > > > include
>> > > > > > > >> > > in the SAN
extension:
>> > > > > > > >> > >
>> > > > > > > >> > > $ getcert
resubmit -i <Request
>> > ID> -D
>> > <hostname>
>> > > > > > > >> > >
>> > > > > > > >> > > ``-D
<hostname>`` can be
>> specified
>> > multiple times, if
>> > > > necessary.
>> > > > > > > >> > >
>> > > > > > > >> > > This should
request a new
>> > certificate that
>> > will
>> > have the
>> > > > server
>> > > > > > DNS
>> > > > > > > >> > > name in the
SAN extension.
>> > > > > > > >> > >
>> > > > > > > >> > > HTH,
>> > > > > > > >> > > Fraser
>> > > > > > > >> > >
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > FreeIPA-users mailing list --
>> > freeipa-users(a)lists.fedorahosted.org
>> > <mailto:freeipa-users@lists.fedorahosted.org>
>> > <mailto:freeipa-users@lists.fedorahosted.org
>> > <mailto:freeipa-users@lists.fedorahosted.org>>
>> > To unsubscribe send an email to
>> > freeipa-users-leave(a)lists.fedorahosted.org
>> > <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > <mailto:freeipa-users-leave@lists.fedorahosted.org
>> > <mailto:freeipa-users-leave@lists.fedorahosted.org>>
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > FreeIPA-users mailing list --
>> > freeipa-users(a)lists.fedorahosted.org
>> > <mailto:freeipa-users@lists.fedorahosted.org>
>> > To unsubscribe send an email to
>> > freeipa-users-leave(a)lists.fedorahosted.org
>> > <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> >
>> >
>> > Hi,
>> >
>> > if the replica is not the renewal master, then certmonger tries to
>> > retrieve the updated cert from the LDAP server (in
>> > cn=<nickname>,cn=ca_renewal,cn=ipa,cn=etc,dc=<basedn>) and
has the
>> > CA_WORKING status until the entry is available.
>> >
>> > You can check if this entry is present on the master server, and on
>> > the replica (the entry will be replicated from master to replica),
>> > and if it contains the latest certificate.
>> >
>> > Flo
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> > To unsubscribe send an email to freeipa-users-leave(a)lists.fedo
>>
rahosted.org
>> >
>>
>>
>