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
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
Dear Flo,
thank you very much indeed!!! That were great instructions and helped. System is back to normal.
Jet me just add a link to this thread, if someone else has the problem:
As we are still running 4.4, we needed to export and import the certificate Flo mentioned from and TO an NSS database. And the commands for doing so are explained here:
https://www.dogtagpki.org/wiki/NSS_Database
Thanks again and have a great weekend
Torsten
freeipa-users@lists.fedorahosted.org