After a recent CentOS update, FreeIPA 4.5 failed to start with the following error message:
Failed to start pki-tomcatd Service
What changed? The following were the 3 packages updated:
I successfully restarted FreeIPA without the pki-tomcatd service:
$ sudo ipactl start --ignore-service-failure
But it’s not ideal to run it without the PKI service. What is going on? According to the log at
java.lang.Exception: Certificate auditSigningCert cert-pki-ca is invalid: Invalid certificate: (-8101) Certificate type not approved for application.
Which cert is that? Where is it? How did it get created? Didn’t FreeIPA create it? Why isn’t it valid? Why doesn’t it give me any additional info?
Eventually I found the certificate location (although I don’t recall how, likely a post on the FreeIPA mailing list):
/var/lib/pki/pki-tomcat/alias -> /etc/pki/pki-tomcat/alias
I ran certutil to find out more about the certificate:
$ certutil -L -d /etc/pki/pki-tomcat/alias
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
That uninformative and misleading error message looked familiar to me. Indeed, I wrote a post about it 7 months ago:
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format
$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca'
The expiration date looked fine, which was the first thing I suspected.
I did note the following, which looked interesting:
Mozilla-CA-Policy: false (attribute missing)
But after reading about that at http://mozilla.github.io/ca-policy/ it looked like it shouldn’t be needed.
Fortunately, I have another working FreeIPA replica that I had not yet upgraded, so I compared the certificates on both systems:
On the IPA replica with errors:
$ sudo certutil -L -d /etc/pki/pki-tomcat/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u
On the working IPA replica:
$ sudo certutil -L -d /etc/pki/pki-tomcat/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u
Note the P trust attribute in the latter. What does it mean? From
-t trustargs Specify the trust attributes to modify in an existing certificate or to apply to a certificate when creating it or adding it to a database. There are three available trust categories for each certificate, expressed in the order SSL, email, object signing for each trust setting. In each category position, use none, any, or all of the attribute codes: · p - Valid peer · P - Trusted peer (implies p) · c - Valid CA · C - Trusted CA (implies c) · T - trusted CA for client authentication (ssl server only)
I modified the trust attributes of the certificate accordingly:
$ sudo certutil -M -t ',,P' -d /etc/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca'
I tried restarting FreeIPA again:
$ sudo ipactl restart Stopping pki-tomcatd Service Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Restarting ipa-otpd Service ipa: INFO: The ipactl command was successful
But why? What does the trust attribute for JAR/XPI mean? I don’t really know — I suppose it means that that the Java code we’re running should trust the certificate. Since I didn’t have this problem when I upgraded the working replica, I’m guessing that I must have done something to change it (and break it) along the way. It likely had nothing to do with the CentOS updates I applied, but I just happened to run into the problem after restarting FreeIPA post-updates.