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.g...@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.g...@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 <rcrit...@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 <f...@redhat.com
>>> > <mailto:f...@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
>>> >         <f...@redhat.com <mailto:f...@redhat.com> <mailto:f...@redhat.com
>>> >         <mailto:f...@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
>>> >                 <ftwee...@redhat.com <mailto:ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>
>>> >                 <mailto:ftwee...@redhat.com <mailto:
>>> ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@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
>>> >                 <ftwee...@redhat.com <mailto:ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>
>>> >                 <mailto:ftwee...@redhat.com <mailto:
>>> ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@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
>>> >                      <ftwee...@redhat.com <mailto:ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>
>>> >                 <mailto:ftwee...@redhat.com <mailto:
>>> ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@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.g...@gmail.com
>>> >         <mailto:prasun.g...@gmail.com> <mailto:prasun.g...@gmail.com
>>> >         <mailto:prasun.g...@gmail.com>>
>>> >                 <mailto:prasun.g...@gmail.com
>>> >         <mailto:prasun.g...@gmail.com> <mailto:prasun.g...@gmail.com
>>> >         <mailto:prasun.g...@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 <
>>> >                      > > ftwee...@redhat.com
>>> >         <mailto:ftwee...@redhat.com> <mailto:ftwee...@redhat.com
>>> >         <mailto:ftwee...@redhat.com>>
>>> >                 <mailto:ftwee...@redhat.com <mailto:
>>> ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@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 <
>>> >                      > > > > ftwee...@redhat.com
>>> >         <mailto:ftwee...@redhat.com> <mailto:ftwee...@redhat.com
>>> >         <mailto:ftwee...@redhat.com>>
>>> >                 <mailto:ftwee...@redhat.com <mailto:
>>> ftwee...@redhat.com>
>>> >         <mailto:ftwee...@redhat.com <mailto:ftwee...@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.c
>>> om
>>> >         <mailto:simon.willi...@thehelpfulcat.com>
>>> >                 <mailto:simon.willi...@thehelpfulcat.com
>>> >         <mailto:simon.willi...@thehelpfulcat.com>>
>>> >                      <mailto:simon.willi...@thehelpfulcat.com
>>> >         <mailto:simon.willi...@thehelpfulcat.com>
>>> >
>>> >                 <mailto:simon.willi...@thehelpfulcat.com
>>> >         <mailto:simon.willi...@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-le...@lists.fedorahosted.org
>>> >         <mailto:freeipa-users-le...@lists.fedorahosted.org>
>>> >                 <mailto:freeipa-users-le...@lists.fedorahosted.org
>>> >         <mailto:freeipa-users-le...@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-le...@lists.fedorahosted.org
>>> >         <mailto:freeipa-users-le...@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-le...@lists.fedo
>>> rahosted.org
>>> >
>>>
>>>
>>
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to