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 ? On Wed, Jul 19, 2017 at 6:23 AM, Fraser Tweedale <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> > > 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,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> > > > > 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 > > > > > > > > > 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> > > > > > > > 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> > > > > > > >> > 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> 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 > > > > > > >> > > > > 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.fedorahosted.org
