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(a)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(a)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(a)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-OR
> G',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>>>
>
> > 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(a)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>>
> > > >
> > > > > 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>>>
>
> > > > > > > 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>>>
> > > > > > >> > 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.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(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>
>
>
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedo
>
rahosted.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