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?
Thanks,
Jeff
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.
rob
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
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?
Thanks,
Jeff
On Tue, Mar 26, 2019 at 6:17 AM Fraser Tweedale 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
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@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@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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" 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" 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" 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" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus:
Jeff
On Tue, Mar 26, 2019 at 10:56 AM Florence Blanc-Renaud 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@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@lists.fedorahosted.org To unsubscribe send an email to
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.fedorahoste...
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@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@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@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to 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.fedorahosted.org >
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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
On Tue, Mar 26, 2019 at 11:29 AM Florence Blanc-Renaud 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" 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@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 aca-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 thesame
> 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@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 ofthe
> > > "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 triedrunning
> > > ipa-certupdate to sync from the other CA master and it completed > > > successfully. The original certificate was not expiredand
> 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 tobe
> 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 waitingfor
> 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@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to 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.fedorahoste...
>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
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.fedorahoste...
On 3/26/19 4:44 PM, Jeff Goddard wrote:
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@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@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@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@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@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.fedorahosted.org > > > > > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to 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.fedorahosted.org >
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Fraser Tweedale -
Jeff Goddard -
Rob Crittenden