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.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 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 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.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
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
On Mon, Jul 17, 2017 at 9:36 AM, Fraser Tweedale 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 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.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 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>
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.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,nonRepudiation,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
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 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 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.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 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>
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.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 >
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'
On Mon, Jul 17, 2017 at 8:58 PM, Fraser Tweedale 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,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 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 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.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>
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>
> 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.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 > >
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 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 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 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.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>
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>
> > 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.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 > > > >
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 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 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 <
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 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 -nServer-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
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>
> 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>
>> > 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.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 >> > > >> > >
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 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 ?
Hi,
you need first to add the CA on the replica with getcert add-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 using getcert 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> 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>> > 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>,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 <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 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.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>> > > > > > > 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>> > > > > > >> > 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.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> > > > > > >> > > > > 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-leave@lists.fedorahosted.org
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 subject: CN=Certificate Authority,O=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 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 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 ?
Hi,
you need first to add the CA on the replica with getcert add-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 using getcert
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> 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 withthe > 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='auditSigningC ert > 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> > 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,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 <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 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 containsthe > > > > 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 > > > > > > > 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> > > > > > > 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> > > > > > >> > 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.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 > > > > > >> > > > > 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-leave@lists.fedo rahosted.org
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 subject: CN=Certificate Authority,O=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> 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 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 ? Hi, you need first to add the CA on the replica with getcert add-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 using getcert 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>>> 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>>> > 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>,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 <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 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.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>>> > > > > > > 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>>> > > > > > >> > 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.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>> > > > > > >> > > > > 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> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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
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 ?
On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud 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 subject: CN=Certificate Authority,O=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> 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 accidentally assigned dogtag-ipa-renew-agent to ipaCert on the replica. It didn't showany errors, and seems to be monitoring. I stopped creating the monitoring requests once I realized this. How do I fix this ?
Hi, you need first to add the CA on the replica with getcert add-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 using getcert 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>>> 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>>> > 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,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 <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 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.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>>
> > > > > > 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_64on 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>> > > > > > >> > 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.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 ofthe 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> > > > > > >> > > > > 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> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedo rahosted.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
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 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 ? Hi, you need first to add the CA on the replica with getcert add-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 using getcert 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, 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 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.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.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 <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.fedorahosted.org
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 using getcert 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.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 > <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. fedorahosted.org >
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 >
I think this has resolved itself on its own after the update to RHEL 7.4. So that was a pleasant surprise.
On Wed, Aug 2, 2017 at 8:53 AM, Prasun Gera prasun.gera@gmail.com wrote:
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 notavailable") # 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-userswrote:
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 forthe -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 `getcertstart-tracking' (or
possibly a bug). > > Anyhow, try: > > > > getcert resubmit -i <request-id> -K <principal-name> -D <dns-name> > > > > Hopefully that will cause the principal nameto
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 renewmy
replica's SSL certificate > > which > > > > > will expire in a month, but I can'tfind 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 withno
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 >
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Fraser Tweedale -
Prasun Gera -
Rob Crittenden