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