This page contains PKI troubleshooting advice. For other issues, refer to the index at Troubleshooting.
IPA won't start, expired certificates
Where available (>= v4.8.0?), the
ipa-cert-fix command can be used to recover from expired system certificate scenarios. See blog post.
If your Certificate Authority certificate is expired, see CA Certificate Renewal page .
For v2.0 see IPA_2x_Certificate_Renewal.
PKI-tomcatd fails to start
After an upgrade of IPA packages, pki-tomcatd fails to start. See Troubleshooting pki-tomcatd fails to start.
If you see something like 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Authentication Error)) or Invalid Credential the likely culprit is the RA agent certificate that IPA uses to authenticate against PKI.
Use getcert list -d /etc/httpd/alias -n ipaCert to show the current status of the certificate tracked by Certmonger. It should be MONITORING.
If it isn't in MONITORING, or it is and things still aren't working, compare the serial number of the certificate with that on other IPA masters:
# certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial
The serial number should match the value of the 2nd integer at:
# ldapsearch -x -h localhost -p 389 -b uid=ipara,ou=People,o=ipaca description
(use port 7389 for 2.x servers)
If they are different this suggests that one has been renewed. Only the most recent is allowed by dogtag. To repair this, go to the master with the most recent certificate:
# certutil -L -d /etc/httpd/alias -n ipaCert -a > /tmp/ra.crt
This will export all the certificates. Edit this file and remove all but the first certificate, You can double-check the result with:
# openssl x509 -text -in /tmp/ra.crt
It should have only the cert with the latest serial #.
Now add it to your cert database:
# certutil -A -n ipaCert -d /etc/httpd/alias -t u,u,u -a -i /tmp/ra.crt # service httpd restart
If the certificate is valid and the ou=People entry is ok then check the PKI logs /var/log/pki or /var/log/pki-ca.
If you see an error like "Failed to connect LDAP server" then try restarting the tomcat process, either pki-cad (for IPA 3.0) or firstname.lastname@example.org.
CRL gets very old
If the main CRL file containing the list of invalidated certificates is old and not updated, make sure you check that:
- There is at least one PKI master server generating the CRL - see CVE-2012-4546 for instructions.
- CRL generation on that server is not blocked by wrong ownership of /var/lib/ipa/pki-ca/publish/ directory or there are no SELinux errors. Consult PKI system for details. (related user case)
External CA renewal with ipa-cacert-manage fails
The second step of external CA renewal may fail for a number of reasons:
- Subject name mismatch
- The new CA certificate issued by the external CA uses a different subject name than the old CA certificate.
- Subject name encoding mismatch
- The new CA certificate issued by the external CA uses the same subject name as the old CA certificate, but it is encoded differently. Some CAs like to re-encode the subject name from certificate signing requests in certificates they issue. This does not work well with NSS, which considers subject names to be equal only if they binary representation is exactly the same. To avoid the problem, configure the external CA to either respect the CSR's encoding, or use UTF8String encoding (which is the FreeIPA default). Microsoft Certificate Services / AD-CS uses PrintableString as the default encoding in subject names. See this GitHub thread for how to observe and configure the AD-CS treatment of Subject DN encoding.
- Subject public key info mismatch
- The new CA certificate issued by the external CA uses a different public / private key pair than the old CA certificate.
- Not a valid CA certificate
- The new CA certificate issued by the external CA is either missing the Basic Constraints extension, or the Basic Constraints extension indicates that the certificate is not a CA certificate.