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 ?

On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud <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>
subject: CN=Certificate Authority,O=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>> 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>>> 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>>>

             > 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>,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>>>


             > > > 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>>
             > > >
             > > > > 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>>>

             > > > > > > 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>>>
             > > > > > >> > 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>>> 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>>
             > > > > > >> > > > > 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>
        To unsubscribe send an email to
        freeipa-users-leave@lists.fedorahosted.org
         <mailto:freeipa-users-leave@lists.fedorahosted.org>





_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 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