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>"
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>"
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>"
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>"
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>> 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>>>
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>
> 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...
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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...