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