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='ca issuer: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>SigningCert cert-pki-ca',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ca SigningCert cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
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>>><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='auditSigningC ert
> cert-pki-ca'
> -
location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCe rt
> 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:prasun.gera@gmail.com <mailto:prasun.gera@gmail.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>>
> > >
> > > > 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>>>
> > > > > > 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>
> > > > > >> > 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:freeipa-users@lists.fe
<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 dorahosted.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