I think the path that is triggered first is from the following code:
if new_cert == old_cert: syslog.syslog(syslog.LOG_INFO, "Updated certificate not available")
# No cert available yet, tell certmonger to wait another 8 hours
return (WAIT_WITH_DELAY, 8 * 60 * 60, '')
This causes the status to change to CA_WORKING for a while. Later, the status changes to the cookie error. The old cert is still valid. So is it supposed to get a new cert ?
On Mon, Jul 31, 2017 at 2:51 PM, Prasun Gera prasun.gera@gmail.com wrote:
They are published, or at least it would seem that way. These were my queries: ldapsearch -h ipa_master -x -D 'cn=directory manager' -b cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc=<basedn> -W ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc=<basedn> -W On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -a On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -a
They all return the same cert.
Also, there was another thread on the mailing list with similar symptoms. I'm not sure if there was a resolution. https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html
On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden rcritten@redhat.com wrote:
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 <flo@redhat.com mailto:flo@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 <flo@redhat.com <mailto:flo@redhat.com> <mailto: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 accidentallyassigned
dogtag-ipa-renew-agent to ipaCert on the replica. It didn't show any errors, and seems to be monitoring. I stopped creatingthe
monitoring requests once I realized this. How do I fix this ? Hi, you need first to add the CA on the replica with getcertadd-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 usinggetcert
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 <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-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>> <mailto: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> <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, FraserTweedale
<ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto: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 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 findany
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 beenhandled
automatically by ipa, > > but > > > > it > > > > > isn't. There have also been quite a fewcert
related posts of late > > which > > > > > makes me think if there are (were) someother
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> <mailto:prasun.gera@gmail.com > <mailto:prasun.gera@gmail.com>> > <mailto:prasun.gera@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@redhat.com > <mailto:ftweedal@redhat.com> <mailto: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> <mailto: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 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.c om > <mailto:simon.williams@thehelpfulcat.com> > <mailto:simon.williams@thehelpfulcat.com > <mailto:simon.williams@thehelpfulcat.com>> > <mailto:simon.williams@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>> > > <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-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@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-leave@lists.fedorahosted.org > <mailto: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 > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@lists.fedo rahosted.org >