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@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@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@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@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/dogtag-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@redhat.com <mailto:ftweedal@redhat.com>
>         <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>
>                 <mailto:ftweedal@redhat.com <mailto:ftweedal@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='auditSigningCert
>                      >    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',nickname='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@redhat.com <mailto:ftweedal@redhat.com>
>         <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>
>                 <mailto:ftweedal@redhat.com <mailto:ftweedal@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-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=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@redhat.com <mailto:ftweedal@redhat.com>
>         <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>
>                 <mailto:ftweedal@redhat.com <mailto:ftweedal@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@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@redhat.com
>         <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>         <mailto:ftweedal@redhat.com>>
>                 <mailto:ftweedal@redhat.com <mailto:ftweedal@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@redhat.com
>         <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>         <mailto:ftweedal@redhat.com>>
>                 <mailto:ftweedal@redhat.com <mailto:ftweedal@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@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
>         <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@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@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@lists.fedorahosted.org
>         <mailto:freeipa-users@lists.fedorahosted.org>
>         To unsubscribe send an email to
>         freeipa-users-leave@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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
>