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 > >