[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera]

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 
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 
> > 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 <
>
> [e-mail]>
> > > > 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 <
>
> [e-mail]
> > > > > 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 <
> > >
> > > [e-mail]>
> > > > > > > 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 <
> > > > >
> > > > > [e-mail]>
> > > > > > >> > 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 <
> > > > > > >> > > > [e-mail]> 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
> > > > > > >> > >
> > > > > > >>
> > > > > > >
> > > > > > >