Certificate was revoked in the future

  • 7009552
  • 12-Oct-2011
  • 18-Sep-2012

Environment

Novell Access Management 3.1
Novell Access Management 3.1 Support Pack 3 IR2 applied.
Novell Access Manager 3.1 Access Administration

Situation

After an IDP server reboot the IDP health showed a problem with a certificate that was being revoked in the future.
The following message was seen:
Error processing OCSP Response for certificate with subject : AM#100101009: AMDEVICEID#1111111111111112:  Root Cause: org.bouncycastle.ocsp.OCSPException: Certificate was revoked in the future!


Resolution:
During troubleshooting it was seen that the response from the OCSP server had a producedAt field with a date and timestamp that was a few seconds later then the current time on the IDP.
So when that packet was processed at the IDP the response from the OCSP server was not valid yet causing a trusted SAML 2.0 Provider to not load correctly.
When a restart of IDP components was done then the time on the IDP server was correct again and the OCSP server reply was accepted.

From the packet trace the following was seen:
OCSP Response: producedAt: 2011-10-03 10:42:49 (UTC) status Good


From catalina.out:
<amLogEntry> 2011-10-03T10:42:47Z SEVERE NIDS Application: AM#100103033: AMDEVICEID#1111111111111111:  Error processing OCSP Response for certificate with subject : Certificate was revoked in the future! </amLogEntry>

<amLogEntry> 2011-10-03T10:42:47Z SEVERE NIDS Application: AM#100105007: AMDEVICEID#1111111111111111:  Error verifying metadata certificates while loading trusted eh.example.nl
 com.novell.nidp.NIDPException: Error processing OCSP Response for certificate with subject : AM#100103003: AMDEVICEID#1111111111111111:  Root Cause: org.bouncycastle.ocsp.OCSPException: Certificate was revoked in the future! </amLogEntry>

As can be seen is that the time on the IDP in this case was 2 seconds off.

When rebooting the server the HW clock was off by a few seconds

Resolution

Reported to engineering to allow for a greater time window under which the OCSP response will be accepted.

The customer reported the following workaround which corrected the few seconds deviation after the server reboot:

They made the following change in /etc/ntp.conf:

server <servername> iburst

Description at ntp.org:
Use iburst in the appropriate peer or server lines in your /etc/ntp.conf file for faster sync (i.e. ~8-15 seconds instead of ~5-10 minutes)