<div dir="ltr">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 ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <span dir="ltr"><<a href="mailto:ftweedal@redhat.com" target="_blank">ftweedal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:<br>
> I can confirm that I see this behaviour too. My ipa server install is a<br>
> pretty stock install with no 3rd party certificates.<br>
><br>
> On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <<br>
> <a href="mailto:simon.williams@thehelpfulcat.com">simon.williams@thehelpfulcat.<wbr>com</a>> wrote:<br>
><br>
> > Yesterday, Chrome on both my Ubuntu and Windows machines updated to<br>
> > version 58.0.3029.81. It appears that this version of Chrome will not<br>
> > trust certificates based on Common Name. Looking at the Chrome<br>
> > documentation and borne out by one of the messages, from Chrome 58,<br>
> > the subjectAltName is required to identify the DNS name of the host that<br>
> > the certificate is issued for. I would be grateful if someone could point<br>
> > me in the direction of how to recreate my SSL certificates so that<br>
> > the subjectAltName is populated.<br>
> ><br>
> > Thanks in advance<br>
> ><br>
> > --<br>
> > Manage your subscription for the Freeipa-users mailing list:<br>
> > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/freeipa-users</a><br>
> > Go to <a href="http://freeipa.org" rel="noreferrer" target="_blank">http://freeipa.org</a> for more info on the project<br>
> ><br>
</div></div>Which version of IPA are you using?<br>
<br>
The first thing you should do, which I think should be sufficient in<br>
most cases, is to tell certmonger to submit a new cert request for<br>
each affected certificate, instructing to include the relevant<br>
DNSName in the subjectAltName extension in the CSR.<br>
<br>
To list certmonger tracking requests and look for the HTTPS<br>
certificate. For example:<br>
<br>
$ getcert list<br>
Number of certificate and requests being tracked: 11<br>
...<br>
Request ID '20170418012901':<br>
status: MONITORING<br>
stuck: no<br>
key pair storage: type=NSSDB,location='/etc/<wbr>httpd/alias',nickname='Server-<wbr>Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/<wbr>pwdfile.txt'<br>
certificate: type=NSSDB,location='/etc/<wbr>httpd/alias',nickname='Server-<wbr>Cert',token='NSS Certificate DB'<br>
CA: IPA<br>
issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317<br>
subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317<br>
expires: 2019-03-22 03:20:19 UTC<br>
dns: f25-2.ipa.local<br>
key usage: digitalSignature,<wbr>nonRepudiation,<wbr>keyEncipherment,<wbr>dataEncipherment<br>
eku: id-kp-serverAuth,id-kp-<wbr>clientAuth<br>
pre-save command:<br>
post-save command: /usr/libexec/ipa/certmonger/<wbr>restart_httpd<br>
track: yes<br>
auto-renew: yes<br>
...<br>
<br>
Using the Request ID of the HTTPS certificate, resubmit the request<br>
but use the ``-D <hostname>`` option to specify a DNSName to include<br>
in the SAN extension:<br>
<br>
$ getcert resubmit -i <Request ID> -D <hostname><br>
<br>
``-D <hostname>`` can be specified multiple times, if necessary.<br>
<br>
This should request a new certificate that will have the server DNS<br>
name in the SAN extension.<br>
<br>
HTH,<br>
Fraser<br>
</blockquote></div><br></div>