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 <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> >> 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 <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>>> 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 >> <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>,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>>> >> >> >> > > > 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>> >> > > > >> > > > > 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>>> >> >> > > > > > > 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>>> >> > > > > > >> > 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>>> 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 >> <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> >> >> >> >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-le...@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 >
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
