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 hoursreturn (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" -aOn replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -aThey 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.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: Did you follow Flo's previous advice and look in LDAP to see if the
> Updated certificate not available". Any way to run some diagnostics on
> the newly added dogtag-ipa-ca-renew-agent on the replica ?
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
> <flo@redhat.com <mailto:flo@redhat.com> <mailto: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
> <mailto:freeipa-users@lists.f> <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='auditSigning Cert
> > cert-pki-ca'
> > -
>
> location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningC ert
> > cert-pki-ca'
> > -
> location='/etc/pki/pki-tomcat/alias',nickname='subsystemCer t
> > cert-pki-ca'
> > -
> location='/etc/pki/pki-tomcat/alias',nickname='caSigningCer t
> > 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-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@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 >
edorahosted.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
>