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