[Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape
Rob Crittenden
rcritten at redhat.com
Fri Feb 12 16:13:33 UTC 2016
Timothy Geier wrote:
>
>> On Feb 10, 2016, at 3:01 AM, Rob Crittenden <rcritten at redhat.com
>> <mailto:rcritten at redhat.com>> wrote:
>>>
>>> [09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL
>>> connection from master_ip to master_ip
>>> [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT
>>> oid="1.3.6.1.4.1.1466.20037" name="startTLS"
>>> [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120
>>> nentries=0 etime=0
>>> [09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime
>>> error -8181 (Peer's Certificate has expired.); unauthenticated client
>>> CN=CA Subsystem,O=XXXXXXX.NET <http://XXXXXXX.NET>; issuer
>>> CN=Certificate Authority,O=XXXXXXX.NET <http://XXXXXXX.NET>
>>> [09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's
>>> Certificate has expired.
>>>
>>
>> Ok, right. The subsystem cert expired on Feb 1 so you'd have to back
>> at least that far in time to do the renewals.
>>
>
>> There are a few entries in ou=People,o=ipaca that need to reflect the
>> current state of certificates as well.
>
> Ah, right, just realized that that’s a base that can looked up
> separately in LDAP..is there anything in particular to look for in there?
Eventually you'll need to confirm that the IPA RA entry matches
correctly but if your CA isn't coming up at all it is putting the cart
before the horse.
>
>>> <snip>
>>>
>>> All of the host keytabs on all of the IPA servers are correct..are
>>> there any other keytabs to check?
>>
>> No, just /etc/krb5.keytab. I think you should focus on getting the CA
>> subsystem certs renewed and then we can look at the other things. So
>> I'd go back in time to Jan 30 or so and just restart certmonger.
>
> After doing so, certmonger appears to run smoothly and goes from
> SUBMITTING to MONITORING but the expiration date on all of the certs
> stays the same. (It’s the same result if ipa-getcert resubmit is run
> against all of the request IDs..quite perplexing)
>
> If we do a total shutdown/rewind/restart, getcert list produces the
> following for these 3 certs during the time shift after the restart:
>
> Request ID '20160209194022':
> status: CA_UNREACHABLE
> ca-error: Internal error
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=XXXXXXX.NET <http://XXXXXXX.NET>
> subject: CN=CA Audit,O=XXXXXXX.NET <http://XXXXXXX.NET>
> expires: 2016-02-01 19:46:48 UTC
> key usage: digitalSignature,nonRepudiation
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20160209194023':
> status: CA_UNREACHABLE
> ca-error: Internal error
> 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=XXXXXXX.NET <http://XXXXXXX.NET>
> subject: CN=OCSP Subsystem,O=XXXXXXX.NET <http://XXXXXXX.NET>
> expires: 2016-02-01 19:46:47 UTC
> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> eku: id-kp-OCSPSigning
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20160209194024':
> status: CA_UNREACHABLE
> ca-error: Internal error
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=XXXXXXX.NET <http://XXXXXXX.NET>
> subject: CN=CA Subsystem,O=XXXXXXX.NET <http://XXXXXXX.NET>
> expires: 2016-02-01 19:46:47 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "subsystemCert cert-pki-ca"
> track: yes
> auto-renew: yes
>
> The most puzzling thing (in my opinion) about this issue is that
> timeshifting doesn’t seem to make any difference at all; pki-tomcatd
> still doesn’t start cleanly (the log entries are very similar) even
> though in theory those certs are no longer expired at that point..it
> seems as if something else is also the issue.
I think we need to see the debug log from a startup failure in the past.
I'd also check the selftests log to see if it is not starting.
Some have reported problems when there is more than one certificate
stored for the subsystem certs in /var/lib/pki/pki-tomcat/alias/.
Theoretically NSS should just ignore this but removing the older certs
has tended to fix things.
So you'd start with something like:
- Save a copy of the 3 db files, just be sure to do so in a safe way
considering it is your root CA
- certutil -L -d /var/lib/pki/pki-tomcat/alias/
- for each nickname run certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n
'<alias>' -a
This should make it fairly apparent if there is more than one. So far
you haven't done anything destructive. We can tackle that if/when we
need to.
rob
More information about the Freeipa-users
mailing list