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(a)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(a)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(a)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(a)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(a)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
> > > >> > >
> > > >>
> > > >
> > > >
> >