Discussion:
[Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA
Simon Williams
2017-04-20 21:46:03 UTC
Permalink
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
Prasun Gera
2017-04-20 23:31:16 UTC
Permalink
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 <
Post by Simon Williams
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
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Fraser Tweedale
2017-04-21 01:06:30 UTC
Permalink
Post by Prasun Gera
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 <
Post by Simon Williams
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
--
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,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_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
--
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
Prasun Gera
2017-04-23 07:32:19 UTC
Permalink
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 ?
Post by Fraser Tweedale
Post by Prasun Gera
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 <
Post by Simon Williams
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
Post by Prasun Gera
Post by Simon Williams
the certificate is issued for. I would be grateful if someone could
point
Post by Prasun Gera
Post by Simon Williams
me in the direction of how to recreate my SSL certificates so that
the subjectAltName is populated.
Thanks in advance
--
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
$ getcert list
Number of certificate and requests being tracked: 11
...
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,nonRepudiation,keyEncipherment,
dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
post-save command: /usr/libexec/ipa/certmonger/restart_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
$ 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
Fraser Tweedale
2017-04-24 00:50:12 UTC
Permalink
Post by Prasun Gera
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
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
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 <
Post by Simon Williams
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
Post by Prasun Gera
Post by Simon Williams
the certificate is issued for. I would be grateful if someone could
point
Post by Prasun Gera
Post by Simon Williams
me in the direction of how to recreate my SSL certificates so that
the subjectAltName is populated.
Thanks in advance
--
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
$ getcert list
Number of certificate and requests being tracked: 11
...
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,nonRepudiation,keyEncipherment,
dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
post-save command: /usr/libexec/ipa/certmonger/restart_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
$ 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
--
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
Prasun Gera
2017-04-24 02:08:11 UTC
Permalink
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 ?
Post by Fraser Tweedale
Post by Prasun Gera
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
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
I can confirm that I see this behaviour too. My ipa server install
is a
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
pretty stock install with no 3rd party certificates.
On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
Post by Simon Williams
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
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
Post by Simon Williams
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
Post by Prasun Gera
Post by Simon Williams
the certificate is issued for. I would be grateful if someone
could
Post by Prasun Gera
Post by Fraser Tweedale
point
Post by Prasun Gera
Post by Simon Williams
me in the direction of how to recreate my SSL certificates so that
the subjectAltName is populated.
Thanks in advance
--
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
$ getcert list
Number of certificate and requests being tracked: 11
...
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,nonRepudiation,
keyEncipherment,
Post by Prasun Gera
Post by Fraser Tweedale
dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
post-save command: /usr/libexec/ipa/certmonger/
restart_httpd
Post by Prasun Gera
Post by Fraser Tweedale
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
$ 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
Prasun Gera
2017-05-01 09:39:58 UTC
Permalink
Any ideas why the replica's certs are not being tracked ? That looks like
an issue in itself. If they are not being tracked, the replica will fail
once they expire. Is there any way to fix the replica ?
Post by Prasun Gera
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 ?
Post by Fraser Tweedale
Post by Prasun Gera
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
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
I can confirm that I see this behaviour too. My ipa server install
is a
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
pretty stock install with no 3rd party certificates.
On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
Post by Simon Williams
Yesterday, Chrome on both my Ubuntu and Windows machines updated
to
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
Post by Simon Williams
version 58.0.3029.81. It appears that this version of Chrome
will not
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
Post by Simon Williams
trust certificates based on Common Name. Looking at the Chrome
documentation and borne out by one of the messages, from Chrome
58,
Post by Prasun Gera
Post by Fraser Tweedale
Post by Prasun Gera
Post by Simon Williams
the subjectAltName is required to identify the DNS name of the
host
Post by Prasun Gera
Post by Fraser Tweedale
that
Post by Prasun Gera
Post by Simon Williams
the certificate is issued for. I would be grateful if someone
could
Post by Prasun Gera
Post by Fraser Tweedale
point
Post by Prasun Gera
Post by Simon Williams
me in the direction of how to recreate my SSL certificates so that
the subjectAltName is populated.
Thanks in advance
--
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
$ getcert list
Number of certificate and requests being tracked: 11
...
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,
Post by Prasun Gera
Post by Fraser Tweedale
dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
post-save command: /usr/libexec/ipa/certmonger/re
start_httpd
Post by Prasun Gera
Post by Fraser Tweedale
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
$ 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
Loading...