On 2/1/19 11:27 AM, Torsten Harenberg via FreeIPA-users wrote:
Dear all,
we are running a pair of IPA servers.
Our master seems to run fine. It had some certificate expired, but we
could solve this by setting the time back, renewing all certificates and
getting him back to today.
Now the "slave" server has also some expired certificates:
[root@ipa ca]# getcert list |grep expires
expires: 2021-01-14 08:53:15 UTC
expires: 2019-01-29 08:07:57 UTC
expires: 2019-01-29 08:07:17 UTC
expires: 2035-03-19 07:41:20 UTC
expires: 2019-01-29 08:06:57 UTC
expires: 2020-08-09 11:55:16 UTC
expires: 2020-08-31 11:55:19 UTC
expires: 2020-08-31 11:55:38 UTC
[root@ipa ca]#
So we tried the same receipe and could update the first of those
certificates, but now starting the 2nd one, we got stuck.
ipa-cacert-manage renew
failes and also the other certificates cannot be updated with
Request ID '20170505060648':
status: MONITORING
ca-error: Server at
"https://ipa.pleiades.uni-wuppertal.de:8443/ca/agent/ca/profileProcess"
replied: 1: Invalid Credential.
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS
Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS
Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=PLEIADES.UNI-WUPPERTAL.DE
subject: CN=OCSP Subsystem,O=PLEIADES.UNI-WUPPERTAL.DE
expires: 2019-01-29 08:07:57 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
a
getcert resubmit -i 20170505060648
brings up the same error message soon after. In the logs we found:
/var/log/pki/pki-tomcat/ca/debug
[25/Jan/2019:10:12:24][http-bio-8443-exec-7]: CertUserDBAuthentication:
cannot map certificate to any user
[25/Jan/2019:10:12:24][http-bio-8443-exec-7]: SignedAuditEventFactory:
create() message created for eventType=AUTH_FAIL
/var/log/messages
Jan 25 10:12:24 ipa certmonger: 2019-01-25 10:12:24 [2829] Server at
"https://ipa.pleiades.uni-wuppertal.de:8443/ca/agent/ca/profileProcess"
replied: 1: Invalid Credential.
Any hint would be really appreciated.
Thanks a lot
Torsten
Hi,
you need to check that the RA certificate is up-to-date, as this cert is
used to authenticate to Dogtag when asking Dogtag to renew the other
certificates.
With IPA < 4.5, this certificate is stored in /etc/httpd/alias with the
nickname ipaCert, and with newer versions the key and cert are in
/var/lib.ipa/ra-agent.{key|pem}.
Pre-requisite: make sure that the master that was repaired is the CA
renewal master:
$ ipa config-show | grep renewal
IPA CA renewal master: <hostname>
1. Check that the master and the replica have exactly the same cert. Run
this command on both and compare the Serial number in the output:
(ipa < 4.5)$ certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial
(ipa 4.5+)$ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem |
grep Serial
If this is not the case, you can copy the cert from the working master
to the replica.
2. Check that the entry uid=ipara,ou=people,o=ipaca contains the right
certificate (on master):
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:: MIIDvDC...jyi5w
description: 2;7;CN=Certificate Authority,O=DOMAIN.COM;CN=IPA
RA,O=DOMAIN.COM
The usercertificate field must contain the new RA certificate and the
description field must contain 2;<serial>;<issuer>;<subject>.
If it's not the case you will have to manually update the LDAP entry
with ldapmodify.
3. Check that the replication is working between master and replica,
otherwise the uid=ipara,ou=people,o=ipaca entry won't be updated on the
replica.
When you reach this point, the getcert resubmit commands should work.
HTH,
flo