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
subject: CN=Certificate Authority,O=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 <f...@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 <ftwee...@redhat.com
>> <mailto:ftwee...@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='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 <
>> ftwee...@redhat.com <mailto:ftwee...@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>,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
>>     <ftwee...@redhat.com <mailto:ftwee...@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.g...@gmail.com <mailto:prasun.g...@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 <
>>     > > ftwee...@redhat.com <mailto:ftwee...@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 <
>>     > > > > ftwee...@redhat.com <mailto:ftwee...@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.willi...@thehelpfulcat.com
>>     <mailto:simon.willi...@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>
>>     > > > > > >> > > > > 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
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>>
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to