I am updating from 4.6.4-10 to 4.6.5-11 on on CentOS 7. The server I am working on is one of three in a production cluster.
The yum update failed and I get the Failed to authenticate to CA REST API in the ipa upgrade log.
I have followed past emails that state the contents of
ldapsearch -D cn=directory\ manager -W -b uid=ipara,ou=people,o=ipaca
must match
/var/lib/ipa/ra-agent.pem
I did find that they did not match so I created an LDIF file to make the LDAP entry match the uid=ipara,ou=people,o=ipaca match /var/lib/ipa/ra-agent.pem but I still get the same problem.
============
BEFORE
dn: uid=ipara,ou=people,o=ipaca description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM;CN=IPA RA,O=MG MT.CROSSCHX.COM uid: ipara sn: ipara usertype: agentType userstate: 1 userCertificate:: MIIDfTC...CUirreECTetw== objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser cn: ipara
snippet of ra-agent.pem
MIIDfTCCA...SLZXf2l
(root)>openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: sha256WithRSAEncryption Issuer: O=MGMT.CROSSCHX.COM, CN=Certificate Authority Validity Not Before: Jan 24 16:44:17 2018 GMT Not After : Jan 14 16:44:17 2020 GMT Subject: O=MGMT.CROSSCHX.COM, CN=IPA RA The serial number, issuer, and subject do not match so I created the following LDIFs.
ipaca-1.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: userCertificate userCertificate: MIIDfTCCA...SLZXf2l
ipaca-2.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: description description: 2;7;O=MGMT.CROSSCHX.COM, CN=Certificate Authority;O= MGMT.CROSSCHX.COM, CN=IPA RA
I then applied them like this
# ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-1.ldif # ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-2.ldif
AFTER
dn: uid=ipara,ou=people,o=ipaca usercertificate: MIIDfTCCA...SLZXf2l description: 2;7;O=MGMT.CROSSCHX.COM, CN=Certificate Authority;O= MGMT.CROSSCHX.COM, CN=IPA RA
===========
None of the certs have expired
(root)>getcert list | grep -i expires expires: 2020-01-25 18:20:55 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2038-01-24 16:43:58 UTC expires: 2020-01-14 16:44:17 UTC expires: 2021-12-07 15:49:57 UTC expires: 2039-09-04 17:51:34 UTC expires: 2020-01-25 18:17:26 UTC expires: 2020-01-25 18:18:20 UTC
When I rerun ipa-server-upgrade manually I still get the same problem. I am able to validate that the contents of the ra-agent.pem file and ldap entry are the same by match content and verifying their MD5 checksum.
When I attempt an ipactl stop / ipactl start it notices that the server needs to be upgrade and attempts the upgrade. How do I recover the server?
On 12/23/19 4:22 PM, Michael Plemmons via FreeIPA-users wrote:
I am updating from 4.6.4-10 to 4.6.5-11 on on CentOS 7. The server I am working on is one of three in a production cluster.
The yum update failed and I get the Failed to authenticate to CA REST API in the ipa upgrade log.
I have followed past emails that state the contents of
ldapsearch -D cn=directory\ manager -W -b uid=ipara,ou=people,o=ipaca
must match
/var/lib/ipa/ra-agent.pem
I did find that they did not match so I created an LDIF file to make the LDAP entry match the uid=ipara,ou=people,o=ipaca match /var/lib/ipa/ra-agent.pem but I still get the same problem.
============
BEFORE
dn: uid=ipara,ou=people,o=ipaca description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM;CN=IPA RA,O=MG MT.CROSSCHX.COM http://MT.CROSSCHX.COM uid: ipara sn: ipara usertype: agentType userstate: 1 userCertificate:: MIIDfTC...CUirreECTetw== objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser cn: ipara
snippet of ra-agent.pem
MIIDfTCCA...SLZXf2l
(root)>openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: sha256WithRSAEncryption Issuer: O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority Validity Not Before: Jan 24 16:44:17 2018 GMT Not After : Jan 14 16:44:17 2020 GMT Subject: O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=IPA RA The serial number, issuer, and subject do not match so I created the following LDIFs.
ipaca-1.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: userCertificate userCertificate: MIIDfTCCA...SLZXf2l
ipaca-2.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: description description: 2;7;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=IPA RA
Hi,
the RA agent cert was probably renewed on the CA renewal master but not updated on your replica. I'm afraid that you picked the wrong cert when updating the LDAP entry (serial=7 is the first RA cert, and after renewal the serial number increases).
Can you first check which host is the renewal master? The source of truth for the RA agent will be the /var/lib/ipa/ra-agent.pem file on this machine. Then refer to the instructions on https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (your source of truth will be the RA agent file on the renewal master and not the ldap entry, as it was overwritten by your ldapmodify commands).
HTH, flo
I then applied them like this
# ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-1.ldif # ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-2.ldif
AFTER
dn: uid=ipara,ou=people,o=ipaca usercertificate: MIIDfTCCA...SLZXf2l description: 2;7;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=IPA RA
===========
None of the certs have expired
(root)>getcert list | grep -i expires expires: 2020-01-25 18:20:55 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2038-01-24 16:43:58 UTC expires: 2020-01-14 16:44:17 UTC expires: 2021-12-07 15:49:57 UTC expires: 2039-09-04 17:51:34 UTC expires: 2020-01-25 18:17:26 UTC expires: 2020-01-25 18:18:20 UTC
When I rerun ipa-server-upgrade manually I still get the same problem. I am able to validate that the contents of the ra-agent.pem file and ldap entry are the same by match content and verifying their MD5 checksum.
When I attempt an ipactl stop / ipactl start it notices that the server needs to be upgrade and attempts the upgrade. How do I recover the server?
-- *Mike Plemmons * Senior Infrastructure Engineer 614-427-2411
https://oliveai.com/ 99 E. Main Street Columbus, OH 43215 oliveai.com http://oliveai.com/ Meet Olive, Your Newest Employee https://youtu.be/9Vf84z9KA6Y
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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Flo, Thank you very much! You gave me the pointer I needed.
Here are the steps that I took following your instructions.
copied /var/lib/ipa/ra-agent.pem from ipa01 (CA master) to ipa03 (failing replica)
ra-agent.pem on CA MASTER
[michaelplemmons@ipa01 ~]$ sudo openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Certificate: Data: Version: 3 (0x2) Serial Number: 234 (0xea) Signature Algorithm: sha256WithRSAEncryption Issuer: O=MGMT.CROSSCHX.COM, CN=Certificate Authority Validity Not Before: Dec 18 16:41:31 2019 GMT Not After : Dec 7 16:41:31 2021 GMT Subject: O=MGMT.CROSSCHX.COM, CN=IPA RA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d1:ef:11:8f:cc:7c:3e:49:b1:14:f0:7c:2e:75: b2:ba:cc:f9:69:1f:f0:cf:8f:62:69:2c:d0:b0:4f: 1f:c4:fd:dd:2c:be:bf:34:4f:f8:f4:b0:12:76:f4: 16:99:67:f4:50:7b:d3:ea:b4:30:0f:bc:7e:ce:69: 43:5e:c1:b9:21:cc:00:9d:8a:f0:4b:05:ae:0e:d1: 13:a3:a5:dc:cd:d4:59:12:53:b3:f9:fa:66:bd:8d: e7:75:94:f5:9b:03:26:21:d0:5d:07:67:e4:38:1f: 53:63:0e:5c:d6:da:b9:4e:47:4d:c7:8f:c7:40:55: fe:74:70:72:10:59:f0:86:9b:31:3a:a0:db:41:6c: 8c:91:68:e0:92:c5:59:4c:c2:77:22:c4:4a:0d:0f: d5:76:a4:c2:88:9c:52:d7:04:be:76:26:dc:85:70: 7e:e7:f0:27:91:ed:ce:60:04:03:6c:6f:86:ae:a2: 59:50:58:52:83:39:a6:98:2a:b1:a9:9a:7b:1e:f3: 48:f6:65:f3:e4:4f:d6:ea:10:a0:3c:55:06:4c:da: d5:c5:ec:6e:eb:c1:e1:ea:49:48:a0:eb:eb:56:87: b6:b2:47:ab:00:55:81:2a:a6:d4:73:5a:fa:d2:31: 9a:ac:fa:b1:5b:2c:67:1a:47:eb:2b:de:d3:cc:2b: ce:05 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier:
keyid:68:28:8C:0C:A7:21:40:39:DA:3B:9D:DA:01:00:5E:05:84:2C:7A:7F
Authority Information Access: OCSP - URI:http://ipa-ca.mgmt.crosschx.com/ca/ocsp
X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Signature Algorithm: sha256WithRSAEncryption 38:aa:62:82:27:20:49:66:11:d3:c3:92:bb:68:51:23:f0:bf: 17:1b:8b:3a:22:46:e9:fa:c7:f4:58:9f:8a:1a:d8:d3:d1:07: 6b:bc:1a:d9:8a:78:ca:7d:d8:6f:65:1f:73:9f:18:db:bd:15: e4:e4:12:e8:b0:81:9a:07:01:bb:e3:98:b3:b2:ca:f6:28:44: cf:d9:c3:81:ff:97:32:ec:65:4a:8c:67:44:11:29:8e:aa:e8: 95:36:9a:60:78:cb:f6:a6:28:0b:19:58:6a:3f:a8:d5:4b:bd: 6f:a9:3a:3d:29:36:45:ba:89:6e:19:9f:a2:6c:65:0b:3f:26: e3:e6:c8:ce:8e:6f:c7:24:da:9f:e0:b7:38:b1:34:24:02:f6: 6d:79:a1:d8:01:c9:ce:51:e5:61:40:8c:3b:3f:57:af:4e:aa: 34:a3:58:10:6b:04:23:72:de:38:bf:2e:1d:3c:36:2c:7a:5c: da:89:e4:7b:de:9a:b3:d9:10:c6:10:8b:1a:01:66:70:2e:d4: e4:4c:ea:6d:74:2a:6d:3d:3f:9c:27:e4:39:54:a1:df:bc:70: 4c:b2:ba:62:77:89:b1:f1:65:53:c5:5b:22:81:f4:bb:f1:0a: d6:b0:dd:2e:f2:0d:a3:56:66:16:fd:3c:92:40:94:8a:ba:de: 10:24:de:b7
---
ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca.ldif
ipaca.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: userCertificate usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw==
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: description description: 2;234;O=MGMT.CROSSCHX.COM, CN=Certificate Authority;O= MGMT.CROSSCHX.COM, CN=IPA RA
---
ldapsearch -D "cn=directory manager" -W -b o=ipaca -LLL -o ldif-wrap=no "(uid=ipara)" usercertificate description
dn: uid=ipara,ou=people,o=ipaca usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw== description: 2;234;O=MGMT.CROSSCHX.COM, CN=Certificate Authority;O= MGMT.CROSSCHX.COM, CN=IPA RA
The description does not match the order of the master and replica for issuer and subject
updated ldif file to fix description
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: userCertificate usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw==
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: description description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM;CN=IPA RA,O= MGMT.CROSSCHX.COM
ran query against ldap
(root)>ldapsearch -D "cn=directory manager" -W -b o=ipaca -LLL -o ldif-wrap=no "(uid=ipara)" usercertificate description Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw== description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM;CN=IPA RA,O= MGMT.CROSSCHX.COM
---
Checking status on master
[michaelplemmons@ipa01 ~]$ ldapsearch -D "cn=directory manager" -W -b o=ipaca -LLL -o ldif-wrap=no "(uid=ipara)" usercertificate description Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca usercertificate:: MIIDfTCCAmWgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFNR01ULkNST1NTQ0hYLkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDEyNDE2NDQxN1oXDTIwMDExNDE2NDQxN1owLTEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xDzANBgNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANHvEY/MfD5JsRTwfC51srrM+Wkf8M+PYmks0LBPH8T93Sy+vzRP+PSwEnb0Fpln9FB70+q0MA+8fs5pQ17BuSHMAJ2K8EsFrg7RE6Ol3M3UWRJTs/n6Zr2N53WU9ZsDJiHQXQdn5DgfU2MOXNbauU5HTcePx0BV/nRwchBZ8IabMTqg20FsjJFo4JLFWUzCdyLESg0P1XakwoicUtcEvnYm3IVwfufwJ5HtzmAEA2xvhq6iWVBYUoM5ppgqsamaex7zSPZl8+RP1uoQoDxVBkza1cXsbuvB4epJSKDr61aHtrJHqwBVgSqm1HNa+tIxmqz6sVssZxpH6yve08wrzgUCAwEAAaOBmDCBlTAfBgNVHSMEGDAWgBRoKIwMpyFAOdo7ndoBAF4FhCx6fzBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9pcGEtY2EubWdtdC5jcm9zc2NoeC5jb20vY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQAY/9UgdtHuaD5VYJQWBR1482uujsApaMgXfHuacX0wUVHO6BvwzqOAjiM00CG4p3yR1IPwDNKcLyslE7o37/EYZLh8PR+WfPBzM7IjOkjlUnRfHnMIuN9Xu1peQIeYEzCvQSjx23EBoVYBofQE7Yxy1W5/ICAQDTKJMmc4KBGcSb3S1VlJoK/cv1dLF1oLXqZYNwuqVJbj9pOJSG0rN+j9wwGGUt11/MgdnQNIc9CaaXJ3oZz4g4q0ZSVn3TEJUzSusEhq64Zjvq1f41pUfQZvB2INL1kDRiDWkqwnG9xWGU9U9weqa+fQgzTO7zptKnp4zxqZAaz6PFjUjSLZXf2l usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw== description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM;CN=IPA RA,O= MGMT.CROSSCHX.COM
Checking status on replica ipa02
[michaelplemmons@ipa02 ~]$ ldapsearch -D "cn=directory manager" -W -b o=ipaca -LLL -o ldif-wrap=no "(uid=ipara)" usercertificate description Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca usercertificate:: MIIDfTCCAmWgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFNR01ULkNST1NTQ0hYLkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDEyNDE2NDQxN1oXDTIwMDExNDE2NDQxN1owLTEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xDzANBgNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANHvEY/MfD5JsRTwfC51srrM+Wkf8M+PYmks0LBPH8T93Sy+vzRP+PSwEnb0Fpln9FB70+q0MA+8fs5pQ17BuSHMAJ2K8EsFrg7RE6Ol3M3UWRJTs/n6Zr2N53WU9ZsDJiHQXQdn5DgfU2MOXNbauU5HTcePx0BV/nRwchBZ8IabMTqg20FsjJFo4JLFWUzCdyLESg0P1XakwoicUtcEvnYm3IVwfufwJ5HtzmAEA2xvhq6iWVBYUoM5ppgqsamaex7zSPZl8+RP1uoQoDxVBkza1cXsbuvB4epJSKDr61aHtrJHqwBVgSqm1HNa+tIxmqz6sVssZxpH6yve08wrzgUCAwEAAaOBmDCBlTAfBgNVHSMEGDAWgBRoKIwMpyFAOdo7ndoBAF4FhCx6fzBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9pcGEtY2EubWdtdC5jcm9zc2NoeC5jb20vY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQAY/9UgdtHuaD5VYJQWBR1482uujsApaMgXfHuacX0wUVHO6BvwzqOAjiM00CG4p3yR1IPwDNKcLyslE7o37/EYZLh8PR+WfPBzM7IjOkjlUnRfHnMIuN9Xu1peQIeYEzCvQSjx23EBoVYBofQE7Yxy1W5/ICAQDTKJMmc4KBGcSb3S1VlJoK/cv1dLF1oLXqZYNwuqVJbj9pOJSG0rN+j9wwGGUt11/MgdnQNIc9CaaXJ3oZz4g4q0ZSVn3TEJUzSusEhq64Zjvq1f41pUfQZvB2INL1kDRiDWkqwnG9xWGU9U9weqa+fQgzTO7zptKnp4zxqZAaz6PFjUjSLZXf2l usercertificate:: MIIDfjCCAmagAwIBAgICAOowDQYJKoZIhvcNAQELBQAwPDEaMBgGA1UECgwRTUdNVC5DUk9TU0NIWC5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xOTEyMTgxNjQxMzFaFw0yMTEyMDcxNjQxMzFaMC0xGjAYBgNVBAoMEU1HTVQuQ1JPU1NDSFguQ09NMQ8wDQYDVQQDEwZJUEEgUkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7xGPzHw+SbEU8HwudbK6zPlpH/DPj2JpLNCwTx/E/d0svr80T/j0sBJ29BaZZ/RQe9PqtDAPvH7OaUNewbkhzACdivBLBa4O0ROjpdzN1FkSU7P5+ma9jed1lPWbAyYh0F0HZ+Q4H1NjDlzW2rlOR03Hj8dAVf50cHIQWfCGmzE6oNtBbIyRaOCSxVlMwncixEoND9V2pMKInFLXBL52JtyFcH7n8CeR7c5gBANsb4auollQWFKDOaaYKrGpmnse80j2ZfPkT9bqEKA8VQZM2tXF7G7rweHqSUig6+tWh7ayR6sAVYEqptRzWvrSMZqs+rFbLGcaR+sr3tPMK84FAgMBAAGjgZgwgZUwHwYDVR0jBBgwFoAUaCiMDKchQDnaO53aAQBeBYQsen8wQwYIKwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhLWNhLm1nbXQuY3Jvc3NjaHguY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAOKpigicgSWYR08OSu2hRI/C/FxuLOiJG6frH9FifihrY09EHa7wa2Yp4yn3Yb2Ufc58Y270V5OQS6LCBmgcBu+OYs7LK9ihEz9nDgf+XMuxlSoxnRBEpjqrolTaaYHjL9qYoCxlYaj+o1Uu9b6k6PSk2RbqJbhmfomxlCz8m4+bIzo5vxyTan+C3OLE0JAL2bXmh2AHJzlHlYUCMOz9Xr06qNKNYEGsEI3LeOL8uHTw2LHpc2onke96as9kQxhCLGgFmcC7U5EzqbXQqbT0/nCfkOVSh37xwTLK6YneJsfFlU8VbIoH0u/EK1rDdLvINo1ZmFv08kkCUirreECTetw== description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM;CN=IPA RA,O= MGMT.CROSSCHX.COM
---
ipa-server-upgrade on failing replica
The upgraded succeeded
On Mon, Dec 23, 2019 at 11:54 AM Florence Blanc-Renaud flo@redhat.com wrote:
On 12/23/19 4:22 PM, Michael Plemmons via FreeIPA-users wrote:
I am updating from 4.6.4-10 to 4.6.5-11 on on CentOS 7. The server I am working on is one of three in a production cluster.
The yum update failed and I get the Failed to authenticate to CA REST API in the ipa upgrade log.
I have followed past emails that state the contents of
ldapsearch -D cn=directory\ manager -W -b uid=ipara,ou=people,o=ipaca
must match
/var/lib/ipa/ra-agent.pem
I did find that they did not match so I created an LDIF file to make the LDAP entry match the uid=ipara,ou=people,o=ipaca match /var/lib/ipa/ra-agent.pem but I still get the same problem.
============
BEFORE
dn: uid=ipara,ou=people,o=ipaca description: 2;234;CN=Certificate Authority,O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM;CN=IPA RA,O=MG MT.CROSSCHX.COM http://MT.CROSSCHX.COM uid: ipara sn: ipara usertype: agentType userstate: 1 userCertificate:: MIIDfTC...CUirreECTetw== objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser cn: ipara
snippet of ra-agent.pem
MIIDfTCCA...SLZXf2l
(root)>openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: sha256WithRSAEncryption Issuer: O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority Validity Not Before: Jan 24 16:44:17 2018 GMT Not After : Jan 14 16:44:17 2020 GMT Subject: O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM,
CN=IPA RA
The serial number, issuer, and subject do not match so I created the following LDIFs.
ipaca-1.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: userCertificate userCertificate: MIIDfTCCA...SLZXf2l
ipaca-2.ldif
dn: uid=ipara,ou=people,o=ipaca changetype: modify replace: description description: 2;7;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM,
CN=IPA RA
Hi,
the RA agent cert was probably renewed on the CA renewal master but not updated on your replica. I'm afraid that you picked the wrong cert when updating the LDAP entry (serial=7 is the first RA cert, and after renewal the serial number increases).
Can you first check which host is the renewal master? The source of truth for the RA agent will be the /var/lib/ipa/ra-agent.pem file on this machine. Then refer to the instructions on
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (your source of truth will be the RA agent file on the renewal master and not the ldap entry, as it was overwritten by your ldapmodify commands).
HTH, flo
I then applied them like this
# ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-1.ldif # ldapmodify -x -D 'cn=Directory Manager' -W -f /root/ipaca-2.ldif
AFTER
dn: uid=ipara,ou=people,o=ipaca usercertificate: MIIDfTCCA...SLZXf2l description: 2;7;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM, CN=Certificate Authority;O=MGMT.CROSSCHX.COM http://MGMT.CROSSCHX.COM,
CN=IPA RA
===========
None of the certs have expired
(root)>getcert list | grep -i expires expires: 2020-01-25 18:20:55 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2020-01-14 16:43:59 UTC expires: 2038-01-24 16:43:58 UTC expires: 2020-01-14 16:44:17 UTC expires: 2021-12-07 15:49:57 UTC expires: 2039-09-04 17:51:34 UTC expires: 2020-01-25 18:17:26 UTC expires: 2020-01-25 18:18:20 UTC
When I rerun ipa-server-upgrade manually I still get the same problem. I am able to validate that the contents of the ra-agent.pem file and ldap entry are the same by match content and verifying their MD5 checksum.
When I attempt an ipactl stop / ipactl start it notices that the server needs to be upgrade and attempts the upgrade. How do I recover the
server?
-- *Mike Plemmons * Senior Infrastructure Engineer 614-427-2411
https://oliveai.com/ 99 E. Main Street Columbus, OH 43215 oliveai.com http://oliveai.com/ Meet Olive, Your Newest Employee https://youtu.be/9Vf84z9KA6Y
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Michael Plemmons