The customer is frequently experiencing rejected messages due to problems updating the crl cache. It seems that sometimes the crl cannot be refreshed because the server that holds the crl is not reacting or not reacting fast enough. In the logs the following messages appear:
ssg_6_0.log:2019-11-15T10:46:30.688+0100 FINE 1579 com.l7tech.server.url.HttpObjectCache: Cache entry for URL 'http://www.csp.uzi-register.nl/cdp/uzi-register_medewerker_op_naam_ca_g3.crl' is too old; contacting server
ssg_6_0.log:2019-11-15T10:46:31.889+0100 FINE 1579 com.l7tech.server.url.HttpObjectCache: Refreshed the cached entry : http://www.csp.uzi-register.nl/cdp/uzi-register_medewerker_op_naam_ca_g3.crl at Fri Nov 15 10:46:30 CET 2019
ssg_6_0.log:2019-11-15T10:46:32.058+0100 WARNING 3932 com.l7tech.server.identity.fed.FederatedIdentityProviderImpl: 2056: Server unavailable for CRL update for http://www.csp.uzi-register.nl/cdp/uzi-register_medewerker_op_naam_ca_g3.crl, using Fri Nov 15 10:46:29 CET 2019 cached version.
What we do not understand is why the message is rejected.
Release : 9.2
Component : API GTW ENTERPRISE MANAGER
Provided a new hot fix - ssg-9.2.00-9087_CR10_hotfix_DE439772.noarch.rpm
We have introduced a new CWP pkix.crl.validateCrlBeforeCacheUpdate, by default this is false, set it to true if you want to validate the CRL before putting into the cache.
Also, as it stands, if the CWP property pkix.crl.validateCrlBeforeCacheUpdate is set to true then no stack trace will be reported in the log file.
if the CWP property pkix.crl.validateCrlBeforeCacheUpdate is set to false, then the stack trace will be in the log file - which will be addressed in a next CR of the release, not in a hot fix.