Flo,
That seems to have resolved everything. I'll note that in the future CA
renewals are best done on the renewal master and hopefully avoid this
situation.
Thanks,
Jeff
Thanks for the update, it's always rewarding to know the team was able
to help resolve an issue!
On Tue, Mar 26, 2019 at 11:29 AM Florence Blanc-Renaud
<flo(a)redhat.com
<mailto:flo@redhat.com>> wrote:
On 3/26/19 4:04 PM, Jeff Goddard via FreeIPA-users wrote:
> Flo,
>
> Thanks for jumping in. When I run the command on both servers I get
> different serial numbers. The domain has been made generic in the
paste
> below.
>
> Renewal master:
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 44 (0x2c)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Issuer: "CN=Certificate
Authority,O=my.domain.org
<
http://my.domain.org>
> <
http://my.domain.org>"
> Validity:
> Not Before: Mon Mar 25 17:46:13 2019
> Not After : Sun Mar 14 17:46:13 2021
> Subject: "CN=CA
Subsystem,O=my.domain.org
<
http://my.domain.org> <
http://my.domain.org>"
> Subject Public Key Info:
> Public Key Algorithm: PKCS #1 RSA Encryption
> RSA Public Key:
> Modulus:
>
> Peer (problematic) CA:
>
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 25 (0x19)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Issuer: "CN=Certificate
Authority,O=my.domain.org
<
http://my.domain.org>
> <
http://my.domain.org>"
> Validity:
> Not Before: Thu Dec 20 18:23:18 2018
> Not After : Wed Dec 09 18:23:18 2020
> Subject: "CN=CA
Subsystem,O=my.domain.org
<
http://my.domain.org> <
http://my.domain.org>"
> Subject Public Key Info:
> Public Key Algorithm: PKCS #1 RSA Encryption
> RSA Public Key:
> Modulus:
>
Hi,
from the output we can see that the cert has been renewed in advance on
the renewal master. The replica still sees it subsystemCert cert-pki-ca
as valid (expiration date not reached yet), meaning that you need to
force its update.
Can you run on the (non-renewal) replica:
getcert list -n "subsystemCert cert-pki-ca"
=> Note the Request ID
getcert resubmit -i <request id>
and check if it is able to download the cert? On non-renewal master,
the
resubmit command will look for a renewed cert in the LDAP server, below
cn=ca_renewal,cn=ipa,cn=etc,$BASEDN. This is why Fraser warned you
about
the replication (if replication is broken, the entry may not be
updated).
HTH,
flo
> Jeff
>
> On Tue, Mar 26, 2019 at 10:56 AM Florence Blanc-Renaud
<flo(a)redhat.com <mailto:flo@redhat.com>
> <mailto:flo@redhat.com <mailto:flo@redhat.com>>> wrote:
>
> On 3/26/19 2:12 PM, Jeff Goddard via FreeIPA-users wrote:
> > Fraser,
> >
> > My thanks to both Rob and you for responding. When I check the
> status of
> > the certificate today I see that is is back in the
"monitoring"
> state
> > but it has not changed the expiration date and there is a
ca-error:
> > ca-error: Invalid cookie: u''. To confirm, the CA I'm
working
> with is
> > not the renewal master. When I check the renewal master
for the same
> > certificate, I see a different expiration date and no errors.
> Running
> > the command ipa-replica-manage list on both servers show
the full
> set of
> > 4 masters and no errors. Can someone provide insight on
why the
> > non-renewal master has a bad date for this certificate and
if its
> > related to the above error, how to rectify the situation?
> >
> Hi,
>
> As I understand, getcert list -n 'subsystemCert cert-pki-ca'
is still
> showing the previous cert.
>
> Can you check if the /etc/pki/pki-tomcat/alias database
contains the
> previous or the renewed cert?
> $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca'
> You can compare the Serial Number with the one on the renewal
> master, or
> the Not before/not after dates. It is possible that certmonger
> output is
> wrong although the cert has been renewed and properly downloaded.
>
> flo
>
> > Thanks,
> >
> > Jeff
> >
> >
> > On Tue, Mar 26, 2019 at 6:17 AM Fraser Tweedale
> <ftweedal(a)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, Mar 25, 2019 at 01:37:00PM -0400, Rob
Crittenden via
> > FreeIPA-users wrote:
> > > Jeff Goddard via FreeIPA-users wrote:
> > > > Hello everyone and thanks for providing the FreeIPA
> platform.
> > > >
> > > > I've got a situation where I have 4 FreeIPA peer
> servers, with
> > 2 of them
> > > > being CAs with replication configured. These are
split
> into 2
> > physical
> > > > locations with 1 CA per site. I was testing
renewal of the
> > > > "nickname='subsystemCert cert-pki-ca"
certificate
in one
> of my
> > sites by
> > > > issuing ipa-getcert resubmit -i [cert ID#]. Now this
> > certificate seems
> > > > to be stuck with a status of CA_Working. Since
its been
> over 4
> > hours
> > > > since I submitted the request I'm wondering if
something
> went
> > wrong and
> > > > where I can begin looking to troubleshoot. I
tried running
> > > > ipa-certupdate to sync from the other CA master
and it
> completed
> > > > successfully. The original certificate was not
expired and
> > other than
> > > > the "CA Working" status there are no
apparent
problems. The
> > server is
> > > > version 4.6.4 running on Centos 7.4. Do I have
reason to be
> > concerned or
> > > > is this expected behavior?
> > >
> > > Only the CA renewal master actually renews
certificates. I'm
> > going to assume
> > > this particular host is not that which means it is
waiting for
> > some other
> > > host to do the renewal and stuff the updated
certificate
> into a
> > location in
> > > LDAP which this will eventually pick up and install.
> > >
> > As long as replication is working properly ;)
> >
> > Also just to clarify: each CA server will renew
host-specific
> > certificates on its own (HTTPS, LDAPS and KDC
certificates). But
> > shared certificates (Dogtag system certs and IPA RA)
are only
> > renewed on the renewal master.
> >
> > Cheers,
> > Fraser
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list --
> freeipa-users(a)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(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
> <mailto:freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>>
> > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
>
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> >
>
>
>
>
>
>
> _______________________________________________
> FreeIPA-users mailing list --
freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>